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(  ^  .  Abstract 

\ — i)  . 

^This  paper  documents  the  design  and  implementation  of  a  discrete  event,  mil¬ 
itary  simulation  using  a  modular  object-oriented  design  and  the  C  programming 
language.  The  basic  simulation  is  one  of  interacting  objects.  The  objects  move 
along  a  predetermined  path  until  they  encounter  another  object.  Objects  react  to 
the  encountered  object  according  to  the  implemented  algorithm.  Object  reaction  op¬ 
tions  are  fight,  evade,  or  do  nothing.  In  the  code’s  current  form  it  is  generic  enough 
to  allow  a  user  the  flexibility  of  creating  an  infinite  number  of  scenarios  bounded 
in  size  by  the  hardware’s  memory  capacity.  The  modularity  of  design  will  allow  for 
easy  expansion  of  object  complexity  and  detail,  «is  well  as  easy  removal  or  replace¬ 
ment  of  functions  or  events.  The  simulation  code  makes  use  of  a  generic  linked  list 
data  structure  and  simulation  driver.  This  adds  yet  another  area  to  the  code  where 
expansion,  removal,  or  replacement  could  be  easily  accomplished.  The  net  result  is 
a  military  scenario  simulation  program  which  is  highly  expandable  and  modifiable, 
yet  compact  enough  to  be  easily  understood.  ^ . 
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AN  OBJECT-ORIENTED  MILITARY  SIMULATION 
BASELINE  FOR  PARALLEL  SIMULATION  RESEARCH 


I.  INTRODUCTION 

This  thesis  deals  with  one  part  of  the  ongoing  research  effort  investigating 
possible  run-time  speedup  of  military  simulation  software  using  parallel  processing. 
Currently,  a  shortage  of  military  simulation  software  for  use  in  Air  Force  Institute 
of  Technology  (AFIT)  research  exists.  The  purpose  of  this  thesis  is  to  provide  a  new 
source  of  this  software. 

1.1  Background 

Recent  development  of  high  speed  parallel  and  distributed  computer  architec¬ 
tures  have  spawned  a  new  interest  in  the  simulation  world.  Fujimoto  believes  that 
these  new  architectural  designs  can  dramatically  speed  up  the  run-time  of  many 
computationally  intensive  problems  such  as  those  in  large  simulations  (12:19).  The 
benefits  of  speedup  are  twofold.  First,  speedup  would  enable  existing  simulations  to 
run  at  higher  speeds,  allowing  for  quicker  decision  making  or  enough  time  to  make 
additional  simulation  runs.  Second,  speedup  would  allow  for  the  development  of 
more  complex,  and  ideally,  more  accurate  simulations. 

At  present,  the  Air  Force  Institute  of  Technology  (AFIT)  does  not  have  the 
ability  to  explore  the  applicability  of  parallel  or  distributed  simulations  dealing  with 
a  military  scenario. 

In  general  there  are  three  requirements  needed  before  one  can  study  parallel 
or  distributed  computer  simulations. 
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•  First,  the  study  requires  a  computer  with  a  parallel  or  distributed  architecture. 
AFIT  has  four  such  systems.  Two  are  Intel  Hypercube  iPSC/ls,  each  using 
thirty-two  INTEL  80286  microprocessors,  one  per  node.  One  iPSC/1  has  a 
vector  processor  at  each  node  and  the  other  has  an  expanded  memory  capacity 
at  each  node.  AFIT  also  has  an  Intel  Hypercube  iPSC/2  which  uses  eight 
of  Intel’s  80386  microprocessors,  one  per  node.  Lastly,  AFIT  has  an  Encore 
Multimax  which  uses  a  shared  memory  architecture  with  sixteen  nodes. 

•  Second,  a  software  package  to  handle  the  protocol  used  for  node  intercommu¬ 
nication  (message  passing  between  the  nodes  (processors))  is  needed.  AFIT 
is  currently  using  a  software  package  called  Spectrum,  a  parallel  simulation 
testbed  developed  by  Paul  Reynolds  at  the  University  of  Virginia  (UVA)  (21), 
which  is  written  in  the  C  programming  language. 

•  Lastly,  the  study  requires  a  simulation  which  is  computationally  intensive, 
has  a  significant  amount  of  code  which  need  not  be  run  sequentially,  and  is 
compatible  with  the  software  used  to  handle  node  intercommunication  (in  this 
case,  compatible  with  Spect-um). 

Parallelizing  a  simulation  can  be  studied  using  many  types  of  simulations. 
However,  the  area  of  particular  interest  to  AFIT  is  parallelizing  battle  and  other 
military  scenario  simulations.  AFIT’s  interest  in  this  area  of  study  stems  not  only 
from  the  fact  that  the  typical  AFIT  student  is  in  the  military,  but  from  specific 
interest  and  requirements  from  sponsoring  organizations,  as  well  as  the  opportunity 
to  explore  claims  made  by  Nicols  as  to  the  limitations  imposed  on  parallelizing 
an  event  driven  battlefield  simulation  (21:141).  ATIT  does  not  have  a  military 
simulation  which  is  appropriate  for  parallelization.  Because  of  the  lack  of  a  military 
simulation  AFIT  hers  only  a  limited  ability  to  explore  the  applicability  of  parallel 
or  distributed  architectures  to  simulation  software.  In  addition  to  the  requirements 
stated  above,  the  simulation  must  also  adhere  to  the  following: 
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•  It  must  contain  the  types  and  number  of  constructs  which  according  to  current 
literature  pose  a  problem  to  parallelization. 

o  It  should  produce  as  an  output  the  information  needed  to  display  the  simula¬ 
tion. 

•  The  code  shall  be  easily  modified,  maintained,  and  reused,  since  it  will  be 
restructured  in  various  parallel  configurations. 

To  meet  AFITs  needs  three  options  exist: 

1.  Find  an  existing  simulation  which  meets  the  stated  requirements. 

2.  Modify  an  existing  simulation  to  meet  the  stated  requirements. 

3.  Create  a  new  simulation  which  meets  the  stated  requirements. 

In  regard  to  the  first,  two  items,  there  are  a  number  of  military  simulations 
currently  in  use  in  the  field,  but  the  following  constraints  preclude  them  from  use. 

•  Most  current  military  simulations  are  coded  in  Fortran  which  is  not.  compatible 
with  UVA’s  simulation  testbed  Spectrum.  Spectrum  is  coded  entirely  in  0. 

•  Most  current  military  simulations  are  very  large,  and  have  been  built  over  time 
by  different  programmers.  This  type  of  construction  makes  translation  to  (' 
and  parallelization  nearly  impossible. 

•  Many  of  the  current  military  simulations  are  classified,  making  it  difficult  if 
not  impossible  to  use  them  in  AFIT’s  parallel  processing  laboratory. 

Thus  the  only  solution  is  option  three.  The  rationale  of  this  thesis  is  therefore 
straightforward:  without  a  military  scenario  simulation  which  meets  the  basic  re¬ 
quirements  stated  earlier,  no  further  research  into  run-time  simulation  speedup  can 
be  made. 
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1.2  Problem  Statement 


Design  and  implement  a  discrete  event  military  scenario  simulation  using  a 
modular  object-oriented  design  approach  and  the  C  programming  language. 

I. 3  Research  Questions 

Answers  to  the  following  questions  are  part  of  this  research  effort: 

1.  Can  a  discrete  event  military  scenario  simulation  be  written  in  C  using  a  mod¬ 
ular  object-oriented  design  approach? 

2.  What  types  of  issues  and  constructs  are  currently  viewed  as  possible  problem 
areas  to  the  parallelization  process? 

3.  What  information  needs  to  be  provided  to  a  remote  graphical  interface  system? 

4.  What,  if  any,  real-time  simulation  inputs  should  the  user  be  allowed  to  make? 

J. /,  Definitions 

Discrete  Event  Simulation  A  simulation  in  which  dependent  variables  change 
discretely  at  specified  points  in  simulated  time  called  event  times  (23:62)  (20:135). 

Event  Something  which  causes  change  in  the  state  of  an  object  or  entity 
(20:136). 

Object  An  entity  which  has  a  state  and  a  defined  set  of  operations  to  access 
and  modify  that  state  (28:204)  (6:20). 

Object-Oriented  Design  A  design  approach  where  the  system  is  viewed  as 
being  composed  of  interacting  objects  instead  of  a  group  of  interacting  functions 
(25:277). 

Time  Driven  (continuous)  Simulation  A  simulation  where  dependent  vari¬ 
ables  may  change  continuously  over  simulated  time  at  set  time  increments  (23:62). 
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1  5  Assumptions 

Several  assumptions  were  made  concerning  this  effort.  First,  the  simulation 
developed  here  will  be  used  solely  for  research  purposes  with  the  intent  of  establish¬ 
ing  feasibility  of operational applications  of  parallel  or  distributed  architectures  to 
simulations,  and  in  particular,  military  simulations.  This  assumption  directly  affects 
issues  of  of  scope.  Second,  DeRouchey’s  work  in  developing  a  generic  graphical  dis¬ 
play  driver  (9)  will  support  this  simulation.  Lastly,  Spectrum  (24),  or  a  comparable 
software  package  written  in  C,  will  be  available  for  use  during  the  follow-on  research 
which  uses  this  code. 

1.6  Scope 

The  extent  of  this  work  is  restricted  by  the  following  limitations: 

•  This  simulation  is  written  to  run  on  a  single  serial  processor.  Parallel  issues 
will  be  considered  during  all  phases  of  design  and  development,  but  this  code 
will  not  be  parallelized  as  part,  of  this  thesis. 

•  The  simulation  should  be  a  “representative”  military  simulation,  but  time  fi¬ 
delity  and  object  characteristics  are  not  goals. 

•  The  simulation  should  provide  output  in  a  fashion  that,  can  be  used  by  a  generic 
graphics  display,  but  not  be  constrained  by  this  interface.  Because  the  graphics 
driver  is  a  separate  but  concurrent  effort  by  DeRouchey  (9),  this  work  should 
be  independent  of  the  graphics  work. 
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II.  LITERATURE  REVIEW 


2.1  Introduction 

The  purpose  of  this  chapter  is  to  at  least  summarize  some  of  the  current  lit¬ 
erature  concerned  with  simulations  in  general,  event  driven  simulations,  and  object- 
oriented  simulations.  Since  C  is  the  required  implementation  language  as  explained 
in  Chapter  One,  its  applicability  to  object-oriented  programming  will  also  be  ex¬ 
plored. 

All  of  the  above  topics  have  already  been  thoroughly  addressed  and  are  'vdl 
understood.  It  is  not  the  purpose  of  this  chapter  to  imply  that  work  of  this  type 
has  never  been  done  before.  However,  as  described  in  Chapter  One,  there  exists  a 
specific  requirement  for  a  simulation  which  is: 

•  a  military  scenario 

•  event  driven 

•  written  in  C 

•  highly  modifiable  and  expandable 

•  is  or  could  create  a  high  computational  load 

•  compact  enough  to  be  understood  by  one  person 

A  simulation  fitting  this  bill  was  not  found,  thus  creating  the  need  for  this  new 

work . 

2.2  Background 

According  to  Thesen  and  Travis,  simulation  in  its  broadest  sense  is  a  perfor¬ 
mance  analysis  tool  which  is  used  as  a  decision  aid  (29:7).  Almost,  any  question  can 
ho  answered  by  a  properly  designed  simulation.  The  proper  design  of  a  simulation 
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can  only  be  done  if  the  problem  is  completely  understood.  Thesen  and  Travis  go  on 
to  point  out  some  common  pitfalls  to  any  simulation.  First.,  creating  a  simulation 
is  an  ait,  requiring  a  special  talent.  The  quality  of  any  analysis  depends  on  the 
quality  of  the  model.  Second,  sometimes  it  is  difficult  to  determine  if  a  particular 
observation  made  during  a  simulation  run  is  representative  of  the  system  behavior 
because  of  the  use  of  randomness  in  the  simulation  (29:7*8).  To  help  avoid  the  first 
pitfall,  the  programmer  must  use  care,  patience,  and  attention  to  detail  while  in  the 
creation  phase.  The  second  pitfall  is  one  of  interpretation,  not  coding,  and  should 
be  easily  handled  if  the  programmer  does  not  forget  what  degree  of  randomness  has 
been  implemented  in  the  simulation  under  study. 

As  defined  in  Chapter  One,  and  as  described  by  many  other  authors,  a  discrete 
event  simulation  is  a  simulation  where  time  is  updated  as  events  occur  and  not 
at  some  predetermined  time  step  (23:62)  (20:135)  (17:11).  In  this  scheme,  events 
are  processed  as  quickly  as  possible,  effectively  deleting  the  “dead  time”  between 
events.  Events  can  occur  at  irregular  time  intervals  which  are  at  least.,  in  part, 
determined  by  what  are  defined  as  events.  Consider  the  following  example  of  a 
discrete  event  simulation:  A  tank  moves  in  a  straight  line  for  100  miles.  If  the  only 
event  defined  is  “reached-turnpoint”  then  this  simulation  has  zero  events  and  t-lie 
simulation  time  clock  is  never  updated.  However,  if  “travel lecLone.mile"  is  an  event, 
then  this  simulation  will  have  one  hundred  events,  and  the  time  clock  should  reflect 
the  time  of  the  last  event. 

There  has  been  enormous  amounts  of  information  published  in  recent  years  on 
the  topic  of  object-oriented  design.  Object  oriented  design  is  one  in  which  the  design 
focuses  on  objects  rather  than  functions,  with  messages  passed  from  object  to  object 
(25:277).  Objects  are  entities  which  have  a  state,  a  defined  set  of  operations  to  access 
or  modify  it,  are  denoted  by  a  name  and  have  restricted  visibility  of  and  by  other 
objects  (28:204)  (6:20)  (7:48-50).  Booch  is  probably  one  of  the  most  widely  recog¬ 
nized  proponents  of  object-oriented  design  today.  His  books  SOFTWARE ’  COM  1*0- 
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NENTS  WITH  ADA  and  SOF'l  WARE  ENGINEERING  WITH  ADA  do  a  good  job 
describing  why,  and  how,  to  use  an  object-oriented  approach  (6)  (7).  Now  that  a 
common  baseline  has  been  established,  the  discussion  can  turn  to  some  of  the  current 
work  relating  to  this  effort. 

2.3  Related  Work 

2.3.1  Simulations  in  Gen:  ral  Simulations  are  much  older  than  the  oldest 
mechanical  computer.  Indeed,  man  has  probably  been  simulating  from  the  point  at 
which  lie  gained  the  ability  to  think  abstractly.  Anytime  a  person  thinks  ahead  to 
“imagine”  the  consequences  of  an  action,  or  sequence  of  actions,  that  person  has 
basically  run  a  simulation,  using  their  brain  as  the  information  processor.  Today, 
with  the  help  of  computers,  we  are  able  to  sin  date  actions,  or  a  sequence  of  act  ions, 
which  for  reasons  of  complexity,  may  not  be  able  to  be  simulated  in  a  single  person's 
head. 

Simulations,  in  general,  are  so  well  understood  that,  they  will  not  be  detailed 
here.  If  more  information  at  this  level  is  needed,  the  references  of  Pritsker  and 
Neelankavil  should  suffice.  However,  the  article  by  Thesen  and  Travis  presented 
some  valuable  information  about  not  only  what  simulations  were,  and  what  they  are 
used  for,  but  what  to  keep  in  mind  as  one  develops  a  simulation.  Those  suggestions 
were  (29:13): 

•  Define  your  objectives  before  simulating. 

•  Use  the  correct  level  of  detail  -  begin  with  a  simple  model. 

•  Select  software  that  is  appropriate  to  your  problem,  level  of  experience  and 
time  frame. 

•  Remember  that  simulation  results  may  be  observations  of  random  variables, 
and  interpret  your  results  accordingly. 
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The  following  subsections  present  highlights  and  pertinent  information  from 
articles,  papers,  or  books  in  the  areas  of  object-oriented  simulation,  military  mod¬ 
elling,  C  as  it  pertains  to  discrete  event  simulations  and  object-oriented  design,  and 
some  background  on  parallel  simulations. 

2.3.2  Object-Oriented  Simulation  The  following  papers  address  object- 
oriented  simulations. 

A  Perspective  on  Object-Oriented  Simulation  (25) 

Probably  the  most  important  point  made  i:.  this  paper,  as  it  pertains  to  the 
work  of  this  thesis,  is  that  an  object-oriented  design  fits  well  into  how  most  t  hings  to 
be  simulated  are  viewed.  To  be  more  specific,  one  can  very  naturally  view  something 
to  be  simulated  as  a  group  of  objects,  or  things,  that  do  something  or  may  hav'* 
something  done  to  them.  Thus,  they  have  legal  operations  which  they  can  do  (e.g. 
the  object  aircraft  might  be  able  to  turn,  fire  a  missile,  or  land),  or  can  be  done  to 
them  (e.g.  the  same  aircraft  may  be  fired  on  by  another  aircraft).  Objects  also  have  a 
corresponding  state  before,  during,  and  after  the  operation.  Roberts  and  Heim  go  on 
to  point  out  construction  of  objects  in  this  manner  help  to  modularize  the  problem  in 
its  earliest  stages  of  analysis.  A  second  major  advantage  to  object-oriented  design  is 
that  simulations  become  more  easily  extensible.  This  is,  of  course,  a  desired  feature 
of  the  simulation  written  as  part  of  this  thesis  work.  A  last  important  advantage 
pointed  out  in  this  paper  is  that  objects  provide  a  natural  baseline  for  concurrency. 
The  idea  here  is  that  each  object,  or  subset  of  objects,  could  be  assigned  a  particular 
processor  of  its  own  and  work  away  until  communication  was  needed. 

Design  and  Implementation  Issues  in  Object-Oriented  Simulation  (5) 

Bezevin  points  out  an  important  aspect  of  coding  a  simulation.  First  and 
foremost  is  the  principle  of  readability.  Having  readable  code  is  always  important 
and  is  obvious  to  anyone  who  has  given  a  copy  of  their  code  to  someone  else  to 
use,  but  it’s  is  of  paramount  importance  to  simulations  arid  the  work  of  this  thesis 
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in  particular.  In  general,  the  only  way  to  determine  if  a  simulation  is  modelling 
something  correctly  is  to  go  back  and  look  at  the  code.  Unverifiable  simulation  code 
is  not  worth  much  if  real  decisions  are  to  be  made  based  on  its  output.  Bezivin's 
point  is  well  taken  here  because  not  only  is  a  simulation  going  to  be  produced  as 
part  of  this  thesis  effort  ,  but  it  is  known  that  the  code  will  be  used  in  follow-on 
work  and  thus  must  be  readable.  The  second  point  Bezevin  makes  is  that  simulation 
code  should  be  efficient.  While  this  is  certainly  true,  especially  for  large  simulations 
where  time  may  be  a  critical  factor,  it  is  luckily  not  a  requirement  of  the  simulation 
developed  for  this  thesis.  On  the  contrary,  a  high  computational  load  is  desired  since 
eventually  this  code  is  to  be  used  to  study  speedup  by  parallelization.  The  second 
half  of  Bezivin’s  paper  deals  with  how  the  object-oriented  parallelization  can  help 
meet  the  needs  of  the  sometimes  opposing  objectives  of  readability  and  efficiency.  As 
found  in  many  of  the  other  references,  the  main  thrust  is  that  by  providing  a  good 
object  model  (e.g.  objects,  and  operations),  the  code  naturally  is  easier  to  follow 
and  normally  more  efficient. 

Some  Experiments  in  Object-Oriented  Simulation  (4) 

in  this  paper,  Bezivin  actually  focuses  on  revealing  greater  flexibility  of  the 
Smalltalk-80  1  simulation  language.  Languages  specifically  designed  for  use  in  cre¬ 
ating  simulations  are  plentiful  (23)  (26)  (14)  (22);  however,  they  are  not  the  focus 
of  t  his  research.  Although  Bezivin’s  paper  revolved  around  Smalltalk-SO,  it  did  give 
valuable  insight  into  a  type  of  simulation  where  there  are  basically  two  types  of  en¬ 
tities,  clients  and  servers.  Clients  are  active  entities  and  the  servers  are  passive.  In 
the  example  given,  Bezivin  modelled  vehicles  travelling  between  cross  road  junctions 
as  active  entities,  and  the  junctions  themselves  where  passive  entities.  This  type  of 
concept,  may  be  applicable  to  this  thesis  work  depending  on  final  design  decisions. 
Bezivin  also  spent  a  good  deal  of  time  on  semaphores  and  monitors,  but  at  this 
time  there  are  no  plans  to  use  shared  data,  so  there  was  limited  applicability  of  this 

'Smalltalk-SO  is  a  trademark  of  the  Xerox  Corporation 
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data.  However,  the  Air  Force  Institute  of  Technology  does  have  a  shared  memory 
parallel  architecture  computer,  and  if  it  is  used  in  the  follow-on  work  to  this  thesis, 
the  information  from  this  paper  will  be  of  value. 

2,3,3  Military  Simulation  Modelling  The  intent  of  this  section  is  to 
present  some  of  the  ideas  or  concepts  of  how  military  models  are  constructed  or 
appear,  either  through  a  specific  example  or  background  data.  A  military  simula¬ 
tion  is  “a  type  of  model  in  which  the  objective  is  generally  to  replicate  a  reasonably 
well  understood  process,  and  for  which  uncertainties  are  treated  by  Monte  Carlo 
method.”  (2:14). 

The  TAC  Brawler  Air  Combat  Simulatio  (3) 

TAC  Brawler  is  a  simulation  of  air-to-air  combat  capable  of  handling  2  -  32 
aircraft.  It  is  written  in  Fortran  and  has  over  150,000  lines  of  code.  In  almost 
all  cases,  the  characteristics  and  behavior  and  reactions  of  TAC  Brawler  entities 
arc  much  more  detailed  than  the  planned  objects  in  the  simulation  to  be  developed. 
However,  it  is  interesting  to  see  how  TAC  Brawler  models  certain  characteristics.  For 
example,  missiles  and  guns  are  both  modelled.  Missiles  take  into  account  guidance, 
seeker,  envelope  and  fuzing.  Sensors  modelled  are  eyes,  radar  and  Infra  Red  Search 
and  Track  (1RST).  Communications  are  explicitly  modelled  as  well  as  Identify- Friend 
or  Foe  (IFF),  defensive  avionics,  radar  jamming  and  Missile  Approach  Warning 
.MAW).  This  paper  has  a  wealth  of  information  on  what  things  can  be  simulated  as 
well  as  limited  information  on  how  it  is  done. 

Two  Aggressive  Aircraft  in  a  Realistic  Shoi't-Range  Combat  as  a  Differential  Game 
Study  (16) 

In  this  paper,  Jarmack  offers  a  rigorous  mathematical  solution  to  a  close  aerial 
combat  with  IR  missiles.  The  level  of  detail,  not  to  mention  its  complexity,  of  the 
material  presented  is  beyond  that  which  is  planned  for  this  thesis  work.  However,  if 
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at  a  later  date,  a  more  rigorous  solution  is  needed  in  this  area,  this  approach  may 
be  applicable. 


Simulation  of  Multiple  Aircraft  Information,  Communication  and  Decision  in  Air 
Combat  (8) 

This  was  ail  extremely  good  article  on  the  modelling  of  communication  and 
decision  making  process.  Although  it  is  not  planned  at  this  time  to  model  communi¬ 
cations  in  the  simulation  to  be  developed  for  this  thesis,  this  is  one  area  which  may 
be  considered  for  consideration  if  time  permits.  Chan  and  Vogel  also  give  a  good 
example  of  a  decision  tree  which  establishes  how  to  assign  target  priorities.  I’n- 
doubtedly,  a  tree  of  this  nature  will  be  used  to  determine  targets  in  the  simulation 
being  developed. 

Military  Make-Believe  (1) 


This  was  really  a  survey  article  of  what  the  state  of  art  simulators  had  to 
oiler,  This  was  a  good  background  piece,  but  did  not  give  much  specific  insight  to 
simulations  at  the  level  of  the  work  of  this  thesis.  The  article’s  focus  was  on  big 
system  simulators  such  as  interactive  simulators  for  the  Mirage  FI  fighter,  AII-6-1A 
Apache  helicopter,  or  the  Mirage  2000  lighter. 


2.3.4  Some  insights  to  C  C  is  a  general-purpose  programming  language 
which  is  touted  for  its  portability,  flexibility  and  power  (30 :*1 ) .  It  features  economy 
of  expression,  modern  control  flow,  data  structures,  and  has  a  rich  set.  of  operators 
(18:xi).  “C  was  originally  designed  for  and  implemented  on  the  UNIX  operating 
system  on  the  DEC  PDP-11,  by  Dennis  Ritchie  The  operating  system,  the  0 
compiler,  and  essentially  all  UNIX  applications  programs  are  written  in  C”(18:xi).  C 
is  widely  used,  and  has  gained  even  more  popularity  as  versions  became  available  for 
use  on  personal  computers.  The  following  articles  or  papers  deal  with  the  application 
of  C  to  object-oriented  programming  or  discrete  event  simulations. 
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It  s  an  Attitude  (19) 


In  this  article,  Linowes  sets  out  to  describe  one  way  it)  which  C  can  be  used 
to  do  object-oriented  programming,  As  is  planned  for  this  thesis  work,  Linowes 
uses  C  structures  as  templates  of  objects.  An  instantiated  structure  thus  creates 
an  object.  Linowes  also  formalizes  a  message  passing  scheme  for  communication 
between  objects.  While  this  makes  clear  the  communication  between  objects,  it  is 
felt  at  this  time  that  it  may  add  an  unnecessary  level  to  object  interaction.  Instead  of 
sending  a  ‘'message”  containing  what  operation  is  to  be  performed,  it  may  be  simpler 
to  just  make  the  operation  to  be  performed  the  message.  Linowes  also  illustrates 
bow  he  handles  inheritance  of  attributes  to  subclasses  of  objects.  Basically,  bo  uses 
a  strategy  of  ^include  chaining,  where  in  the  structure  definition  of  one  object  he 
uses  ^include  to  include  another  file  thus  enabling  inheritance  to  occur.  This  seems 
like  a  reasonable  approach  to  inheritance  if  it  is  used  in  this  thesis  work. 

Object-Oriented  Programming  A#  <1  Programming  Style  (32) 

White's  article  was  another  example  of  how  C  could  be  used  to  code  using 
an  object-oriented  approach.  White  is  a  little  more  detailed  in  his  coverage  than 
Linowes,  but  is  nearly  the  same  in  how  he  handles  messages  and  inheritance.  White 
does  separate  “messages”  from  what  he  calls  “methods”  where  Linowes  does  not.  In 
White’s  version,  “messages”  get  sent  to  an  object,  where  something  decides  what 
"method”  (operation)  to  invoke.  It  really  just  seems  to  be  a  rather  minor  difference, 
but  it  is  a  slightly  different  twist.  The  rest  of  White’s  article  focused  on  C++  and 
how  it  can  be  used  in  object-oriented  programming. 


C  Based  Discrete  Event  Simulation  Support  System  (2“) 

This  paper  describes  a  0  based  simulation  environment  for  creating  and  exe¬ 
cuting  discrete-event  simulation  models  in  which  the  event,  routines  are  coded  in  C. 
The  system  described  by  Selvaraj  et.al.  is  divided  into  eight  task  modules.  The  two 
most  important  modules  are  the  executive  controller  and  the  memory  management 
module.  The  executive  controller  module  is  similar  to  the  Generic  Simulation  Driver 
in  the  appendix  of  this  thesis.  It  basically  executes  the  simulation,  placing  and  tak¬ 
ing  event  entities  off  the  “simulation  calendar”  (event  list)  until  no  more  events  exist 
to  be  executed  or  the  simulation  gets  a  termination  event.  In  the  Generic  Simulation 
Driver  memory  management  is  not  handled  as  a  .eparate  issue;  instead  it  is  done  on 
an  as-needed  basis  within  the  code. 

2.3,5  Parallel  Simulation  While  writing  a  parallel  simulation  is  not  the 
objective  of  this  thesis  work,  writing  a  simulation  that  can  be  parallelized  certainly 
is.  Thus,  some  knowledge  of  what  parallelization  may  entail  is  definitely  an  area  to 
be  considered. 

,-t  Survey  of  Parallel  Computer  Architectures  (10) 

Duncan  starts  his  article  off  by  addressing  Flynn’s  taxonomy  (11).  Fly  tin  clas¬ 
sifies  architectures  on  the  presence  of  single  or  multiple  data  streams  of  instructions 
and  data.  Flynn’s  M1MD  (multiple  instruction,  multiple  data  stream)  machines 
are  the  types  of  parallel  computers  availabb  at  the  A'..  Force  Institute  of  '’.ethnol¬ 
ogy,  and  as  such,  will  be  what  is  discussed  here.  MIMD  machines  involve  multiple 
processors  autonomously  executing  diverse  instructions  on  diverse  data.  MIMD  ar¬ 
chitectures  are  generally  more  complex  then  machines  of  Flynn’s  ot  her  classifications, 
but  MIMD  machines  can  also  mimic  the  other  machines  i  chavi  jr  if  necessary.  The 
next  important  area  within  MIMD  machines  deals  with  whether  the  machine  has  a 
shared  nunnery  approach,  where  all  the  processors  have  immediate  and  direct  access 
to  some  central  memory. or  whether  the  machine  has  a  distributed  memory  scheme. 
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whereby  each  processor  has  its  own  memory  and  access  to  another  processor's  mem¬ 
ory  is  indirectly  through  some  type  of  message.  As  stated  in  Chapter  One,  (he  Air 
Force  Institute  of  Technology  has  both  distributed  memory  machines  and  a  shared 
memory  machine.  It  is  apparent,  at  this  point  that  a  significant,  problem  to  be  avoided 
when  designing  any  program  which  will  be  run  on  a  distributed  memory  machine  is 
the  use  of  global  variables.  It  should  be  obvious,  but  excessive  use  of  giobals  will 
create  a  large  communication  overhead  caused  by  message  passing  to  keep  variables 
updated.  Shared  memory  machines  do  avoid  this  shortfall,  but  in  shared  memory 
machines  other  problems  like  data  access  sychronization  must  be  solved. 

Parallel  Discrete  Event  Simulation  (12) 


This  paper  deals  with  the  execution  of  a  single  simulation  program  applica¬ 
tion  in  a  set  of  concurrently  executing  processes,  or  more  simply  put,  the  parallel 
execution  of  a  single  simulation.  More  interesting  than  the  general  objective  of  this 
paper  was  the  section  called,  “Why  Is  Parallel  Discrete  Event  Simulations  Hard?". 
Fujimoto  points  a  finger  immediately  to  global  data  structures,  but  of  course  this  is 
not  surprising.  He  also  discusses  how  hard  it.  is  to  ensure  the  proper  execution  se¬ 
quence  of  events,  pointing  out  that  the  constraints  that  dictate  which  computations 
must  be  executed  before  which  others  is  often  quite  complex  and  data  dependent. 
It  is  hero  that  overlap  into  the  synchronization  area  becomes  evident.  It  appears, 
however,  that  clever  partitioning  of  the  problem  may  help  to  alleviate  part  of  the 
precedence  problems. 

Alt  Empirical  Study  of  Data  Partitioning  and  Flcplieaiion  in  Parallel  Simulation  (31 } 


Wieland’s  article  looked  at  the  issue  of  partitioning  in  a  parallel  simulat  ion.  In 
particular  he  focused  on  the  issue  of  proximity  detection  between  object  s  in  adjacent 
sectors,  where  sectoring  has  been  chosen  as  tire  parallel  partitioning  strategy.  An 
obvious  strategy  to  handle  movement  between  sectors  is  to  create  an  event  corre¬ 
sponding  to  travel  across  a  boundary.  At  that  event,  time  an  object-  could  he  “handed 
over”  from  the  processor  currently  cont  rolling  the  object  to  the  processor  rout  rollinn 
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the  new  sector.  This  strategy  is  straightforward  enough,  but  the  more  subtle  issue 
is  how  to  handle  detection  between  objects  that  are  near  the  borders  but  still  in 
different  sectors.  Wieland  mentions  a  number  of  strategies  like  use  of  a  buffer  zone 
between  sectors,  overlapping  sectors,  or  data  replication  as  an  object  and  its  sensor 
zone  move  from  one  sector  to  another.  This  last  strategy  intrinsically  sounds  best 
since  sensor  zones  can  then  be  of  differing  sizes  as  is  not  the  case  for  the  other  strate¬ 
gies.  One  last  note  of  particular  interest  are  his  comments  on  proximity  detection 
within  a  sector.  Wieland  comments  that  a  quadratic  equation  can  be  used  to  solve 
for  the  time  at  which  two  objects  will  first  come  in  contact  with  one  another  and 
the  time  at  which  they  will  lose  contact  with  each  other.  This  notion  will  be  furt  her 
explored  as  the  design  of  the  simulation  for  this  thesis  progresses. 


2-11 


III.  THE  MODEL 


3. 1  Introduction 

This  chapter  is  broken  into  three  distinct  areas:  the  overall  model  of  battle  or 
high  level  design,  a  more  detailed  look  at  the  model  of  battle  or  low  level  design,  and 
an  explanation  of  program  interfaces.  In  the  high  level  design  area  there  are  three 
topics  of  discussion,  the  objects  which  will  be  available  for  instantiation  and  use  in  a 
given  scenario,  the  events  which  may  affect  object  attributes,  and  the  basic  models 
for  how  objects  perceive,  move,  and  fight.  In  the  low  level  design  area  objects  will 
be  viewed  in  detail,  and  the  functions  which  support  the  events  will  be  discussed. 
The  object  discussion  will  include  attributes,  and  rationale  for  the  object’s  existence. 
The  final  area  defines  the  interface  between  the  simulation  driver  (what  executes  the 
simulation),  and  the  actual  simulation. 

3.2  System  Overview 

Here  is  the  “big  picture”,  without  regard  to  describing  how  the  code  is  actually 
accomplishing  any  of  these  actions.  Figure  3.1  illustrates  the  big  picture  as  seen  from 
the  outside.  The  user  must  create  a  scenario  file  (as  described  in  this  chapter  and 
Appendix  F).  Once  created,  the  executable  rizsim  simulation  code  is  executed  using 
the  created  scenario  file.  The  simulation  produces  an  output  (at  this  time  a  file), 
which  is  read  by  the  display  driver  which  graphically  displays  the  simulation  output. 
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Figure  3.1.  The  “Big  Picture” 
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Figure  3.2  depicts  a  simple  two  dimensional  representation  of  a  typical  sim¬ 
ulation  scenario.  At  time  t  there  are  eight  objects  in  the  simulation,  a  flight  of 
three  aircraft  approaching  from  the  southwest,  a  single  ship  approaching  from  the 
northwest  on  an  intersecting  path  with  the  flight  of  three,  three  tanks  moving  in  a 
northwestly  direction,  and  one  other  single  ship  moving  northwest.  At  time  A t  later 
two  of  the  flight  of  three  have  been  destroyed  as  well  as  the  single  ship  attacker. 
Now  only  one  of  the  flight  of  three  remains,  along  with  the  three  tanks  and  the  other 
single  ship.  By  some  other  At  later,  the  remaining  single  ship  has  turned  north  to 
evade  the  other  aircraft  as  the  other  aircraft  flew  by.  On  the  last  leg  of  the  single 
ship’s  journey,  the  single  ship  destroys  the  three  tanks. 
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3.3  High  Level  Design 

The  general  system  model  is  one  of  interacting  objects.  Moveable  objects 
(vehicles)  have  a  predetermined  route  as  part  of  the  input  scenario,  which  may  or 
may  not  be  altered  depending  on  obstacles  or  threats  encountered.  Moveable  objects 
may  have  a  predetermined  target  or  destination  as  an  objective,  or  may  be  in  search 
of  a  target  of  opportunity.  Stationary  objects,  such  as  Surface-to-Air  Missle  (SAM) 
sites,  will  attack  any  valid  target  within  range  if  the  site  has  the  resources  to  do 
so.  Once  the  simulation  has  begun,  objects  move  along  their  predetermined  routes 
carrying  out  their  respective  missions.  If  an  obstacle  or  threat  is  encountered  along 
the  route,  an  event  (e.g.  entered_sensor .range)  is  scheduled  to  handle  the  situation. 
The  vehicle  will  choose  to  either  attack,  evade,  or  take  no  action,  in  response  to  the 
obstacle  or  threat.  Although  all  objects  are  autonomous  entities  reacting  to  threats 
or  obstacles  separately,  it  is  expected  that  similar  objects  (e.g.  two  F-15s  flying  the 
same  route  with  a  half  second  seperation)  will  react  similarly  to  the  same  threal 
or  obstacle.  This  is  because  the  algorithm  used  by  the  F-15s  to  determine  their 
course  of  action  will  be  the  same.  The  simulation  will  continue  until  a  termination 
event  is  executed  or  no  more  events  are  pending  in  the  Next  Event  Queue  (NEQ). 
A  termination  event  can  be  scheduled  at  any  time  by  using  the  end_sim  function 
available  in  the  generic  simulation  driver. 

3.3.1  The  Objects  The  design  strategy  used  in  defining  objects  for  this 
simulation  was  to  keep  the  objects  as  generic  as  possible  without  being  unrealistic  as 
to  the  breadth  of  application  of  any  one  object.  Stated  simply,  there  is  no  “super” 
object  that  can  be  instantiated  to  create  any  entity  type  in  the  system.  However, 
many  of  the  semi-generic  objects  will  be  able  to  be  instantiated  to  create  a  limited 
number  of  seemingly  different  object  types.  A  good  example  of  this  is  the  object 
“sensors”  which  can  be  instantiated  as  a  number  of  different  sensor  types  from  eyes 
to  radar. 
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The  objects  are  those  entities  within  the  simulation  scenario  which  make  up  the 
“order  of  battle”.  The  order  of  battle  as  used  here  refers  to  the  types  and  amounts 
of  instantiated  objects  which  will  be  players  in  the  scenario  to  be  run.  Table  3.1 
lists  all  the  object  types  which  are  available  to  the  user  for  instantiation.  Figure  3.3 
shows  the  relationships  between  the  objects  in  a  given  scenario.  Object-attribute 
relationships  are  addressed  in  the  low  level  design  section. 

_ Object  Types _ 

object  _attri  bu  tes 
performance-characteristics 
sensors 
armaments 
defensive-systems 
route-data 
operator 
target -list 
master_obj-!ist 

Table  3.1.  Simulation  Object  Types 

Objects  instantiated  using  the  “object-attributes”  type  are  probably  the  most 
important  of  all  the  objects  within  the  scenario.  It  is  the  movement  of  these  objects 
which  gives  the  simulation  much  of  the  computational  complexity  sought  by  this 
work.  The  object-attributes  type,  as  are  many  of  the  other  object  types,  is  a  skeleton 
definition  where  the  user  fills  in  the  applicable  attributes  with  the  correct  values  when 
the  object  is  instantiated.  By  simply  providing  zeros  as  the  velocity  vector  attributes 
and  no  route  points  other  than  the  object’s  current  location,  a  user  has  effectively 
created  a  stationary  object.  Thus,  the  object-attributes  type  can  be  instantiated  to 
cover  a  wide  variety  of  objects,  both  moving  and  stationary. 


has  acced 


defensive  .systems 


Figure  3.3.  Object  Relationships 


Since  each  moving  object  will  have  some  route  associated  with  it,  there  is  a 
need  for  the  “route-data”  object.  Even  a  vehicle  that  goes  nowhere  will  have  a  route 
associated  with  it,  but  its  route  will  be  a  single  point.  The  route  data  will  provide 
the  simulation  with  the  future  locations  of  an  object.  This  information  is  critical  in 
determining  the  vehicle’s  yaw,  pitch,  and  velocity  vectors. 

“Sensors”,  like  vehicles,  can  be  instantiated  with  differing  attributes,  thereby 
creating  different  sensors.  Many  of  the  vehicles  may  employ  the  same  type  of  sensor 
and  some  of  the  vehicles  may  be  equipped  with  a  number  of  different  sensors.  Thus 
sensors  logically  map  to  an  object  class.  The  association  of  a  sensor,  or  group  of 
sensors,  with  a  particular  object  gives  the  simulation  the  ability  to  determine  what 
an  object  can  or  will  perceive. 

The  rationale  behind  the  creation  of  the  “armaments”  and  “defensive-systems” 
objects  is  essentially  the  same  as  for  sensors.  The  association  of  a  particular  type  of 
armament,  such  as  armament  type,  range,  destructive  power,  etc.  with  an  instan¬ 
tiated  object  provides  the  simulation  with  information  which  can  be  used  during  a 
fight  sequence.  Examples  of  armaments  could  include  systems  such  as  sidewinder 
missiles,  50  caliber  machine  guns,  or  surface-to-air  missiles.  As  with  armaments,  the 
defensive  systems  object  provides  the  simulation  with  information  as  to  what  type 
of  defensive  systems  an  object  is  equipped,  if  any.  Examples  of  defensive  systems 
are  chaff,  flares,  or  jammers. 

The  intent  of  the  “operator”  object  is  used  to  factor  in  intangible  qualities  such 
as  experience  and  threat  knowledge.  The  values  assigned  to  these  qualities  could  be 
used  to  help  determine  whether  an  attack  will  be  successful  (e.g.  the  armament  hit 
the  target).  Operator  qualities  could  also  be  factored  into  the  operator  evaluation 
function  where  decisions  regarding  a  course  of  action  (such  as  attack,  evade,  or  take 
no  action)  are  made. 

The  “performance-characteristics”  object  is,  as  the  name  implies,  where  the 
performance  characteristics  pertaining  to  a  particular  vehicle  are  stored.  The  uses  of 
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the  information  found  in  this  object  could  be  in  any  calculation  needing  performance 
data,  especially  maximum  or  minimum  limits  such  as  climb,  turn  or  acceleration 
limits. 

The  “targetJist”  object  is  a  linked  list  containing  pointers  to  each  object’s 
targets  and  each  target’s  location.  This  information  is  used  in  determining  if  an 
encountered  target  should  be  engaged. 

The  “master _obj .list”  object  is  a  linked  list  containing  pointers  to  all  the  ob¬ 
jects  in  the  system.  Access  to  this  information  is  critical  in  the  determination  of 
sensor  contacts  and  collision  detection. 

3.3.2  The  Events  The  events  are  those  happenings  or  occurrences  which 
may  cause  the  system  state  to  change.  Events  generally  cause  some  process  or 
function  to  execute  which  is  the  driving  mechanism  which  physically  changes  the 
system  state.  As  was  the  case  for  the  objects,  the  design  of  the  events  used  in  this 
simulation  software  calls  for  a  generic  approach  to  their  implementation.  Again, 
there  are  limitations  as  to  how  far  one  can  carry  a  generic  approach,  but  here, 
too,  reasonableness  must  prevail.  As  a  rule,  events  should  apply  equally  well  to  all 
instantiations  of  objects  within  a  class  (e.g.  the  reach-turnpoint  event  should  apply 
equally  well  to  any  moving  object).  Events  will  be  implemented  as  C  functions 
which  in  turn  will  call  the  applicable  functions  to  make  adjustments  to  scenario 
object  attributes. 

Table  3.2  lists  the  events  which  are  currently  used  in  the  simulation  work. 

The  reached.turnpoint  event  sets  a  number  of  functions  into  motion.  As  a 
consequence  of  reaching  a  turnpoint,  the  vehicle’s  current  position  is  updated.  Up¬ 
dating  a  vehicle’s  position  encompasses  five  tasks.  First,  the  new  position  coordinates 
are  transferred  from  the  route  data  to  the  current  location  attributes  of  the  vehicle. 
Next,  the  current  orientation  of  the  vehicle  is  calculated  and  the  applicable  attributes 
are  updated.  Then,  the  current  velocity  vectors  are  calculated,  again  updating  the 
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Table  3.2.  Simulation  Events 

appropriate  attributes.  The  object’s  current  time  is  updated  and  finally,  after  all 
attributes  have  been  updated,  the  information  is  sent  to  the  graphics  display  or  to 
an  intermediate  file.  Once  this  has  been  accomplished,  the  sensor.check  function 
is  called  to  help  determine  what  the  next  event  to  be  scheduled  will  be.  Ideally, 
in  the  absence  of  any  intermediate  sensory  contacts  or  collisions  (if  no  sensors  arc 
operating),  the  next  event  will  be  the  next  event  point  from  the  vehicle’s  route  data. 
Thus,  in  order  to  determine  what  the  next  event  really  is,  a  check  of  the  vehicle’s 
projected  path  must  be  made  against  all  other  paths  and  positions  of  stationary 
objects  to  determine  whether  there  will  be  a  sensory  contact  or  collision  prior  to  the 
next  predetermined  event  point.  Only  then  can  the  proper  event  be  scheduled. 

The  made_sensor_contact  event  is  basically  a  decision  point.  If  this  event  oc¬ 
curs,  an  object  has  come  within  sensory  range  of  another  object.  The  perceiving 
object  at  this  point  must  decide  what  to  do  about  what  it  perceives.  Thus,  it  must 
interrogate  the  source  to  determine  whether  it  is  a  friend  or  enemy,  and  if  it  is  an 
enemy,  decide  on  a  course  action  such  as  attack,  evade,  or  take  no  action.  Thus, 
the  execution  sequence  is:  update  the  vehicle’s  position  (the  same  five  step  process 
from  above),  call  the  operator-evaluation  function,  schedule  the  event  determined  in 
operator-evaluation,  and  perform  a  sensor  check  to  schedule  an  intermediate  event 
if  one  is  found. 

The  entered.sensor_range  event  is  identical  in  function  to  reached.turnpoint.. 


3-10 


The  position  of  the  object  entering  the  sensor  range  of  another  object  is  updated  as 
above,  and  then  the  sensor  check  function  is  called  to  determine  what  the  next  event 
will  be  for  the  object  in  question.  Although  the  subsequent  function  calls  are  the 
same  as  for  both  enter.sensor_range  and  reached_turnpoint,  enter_sensor_range  is  a 
separate  and  distinct  event  caused  by  sensor  range  information  and  the  proximity  of 
another  object.  A  reached.turnpoint  event,  of  course,  has  nothing  to  do  with  either 
of  these  factors.  It  should  be  noted  here  that  for  every  enter  jsensor.range  event  there 
should  be  a  corresponding  made_sensor_contact  event.  This  makes  sense  since  every 
time  a  object  senses  another  object,  the  other  object  is  coming  into  sensor  range. 

The  collision_distance_reached  event  basically  means  two  objects  have  reached 
the  same  point  in  space  at  the  same  time.  The  collision.distance_reached  event 
will  most  likely  involve  a  vehicle  or  vehicles  without  sensoring  capabilities,  either 
because  no  sensors  are  present  or  they  are  malfunctioning  and  the  vehicle  is  oper¬ 
ating  in  the  blind.  As  with  all  other  events  thus  far,  the  vehicle’s  position  must 
be  updated.  A  damage_assessment  function  call  would  determine  the  extent  of  the 
damage  and  adjust  the  appropriate  vehicle  attribute  accordingly.  If  a  total  destruc¬ 
tion  has  occurred,  then  the  damage-assessment  would  also  send  the  graphics  display 
a  destruction  message  signaling  that  the  entity  no  longer  needs  to  be  displayed.  At 
that  point  the  entity  will  no  longer  exist  within  the  simulation.  In  the  case  of  tot  al 
destruction,  damage-assessment  will  also  call  the  unschedule.events  function  which 
will  unschedule  any  event  for  which  the  now  dead  entity  was  previously  scheduled. 

The  ordnance-released  event  is  scheduled  as  a  result  of  the  operator-evaluation 
function  determining  that  an  attack  will  take  place.  The  ordnance-released  event 
basically  starts  a  missile  on  its  way  to  a  target.  The  missile  acts  as  any  other  moving 
object  in  the  system,  but  of  course  it  is  moves  quite  a  bit  faster.  The  missile  moves 
along  a  predetermined  route.  If  it  encounters  the  target  before  the  missile  terminates 
at  its  last  routepoint,  an  ordnance.reached.target  will  be  scheduled. 

The  ordnance.reached.target  event  is  scheduled  in  the  sensor.check  function 
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if  sensor.check  determines  the  missile  catches  the  object  which  it  is  chasing.  Ord- 
nance_reached_target  updates  the  position  of  both  missile  and  target,  then  it  calls 
hit_miss  to  determine  whether  the  missile  actually  scored  a  hit.  In  the  event  of  a  hit, 
damage-assessment  is  called  by  hit_miss  to  determine  the  extent  of  damage.  Since 
there  may  be  a  considerable  lag  time  between  the  firing  or  release  of  the  ordnance 
and  its  impact,  due  to  the  ordnance  speed  and  distance  to  the  target,  it  is  reasonable 
to  model  the  ordnance  impact  as  a  separate  event. 

3.3.3  Models  for  Perceive,  Move,  and  Fight 

Perceive:  The  model  for  perceive  deals  with  how  an  object  becomes  aware  of 
another  object.  Perception  takes  place  through  the  use  of  some  sensing  equipment. 
Examples  of  sensing  equipment  are  radar,  or  the  human  eye. 

The  simulation  system  handles  perception  between  objects  by  exhaustive  com¬ 
parisons.  Typically,  before  the  next  predetermined  event  can  be  scheduled  from  a 
vehicle’s  route  data,  the  system  must  determine  if  an  intermediate  event  needs  to  be 
scheduled.  Thus  the  basic  model  for  perceive  is  given  here: 

•  Compare  the  vehicle’s  sensor  zone  path,  from  its  current  location  to  its  next 
preplanned  event  location  (from  its  route  data),  against  all  other  vehicle  sensor 
zone  paths  or  stationary  object  sensor  zone  locations. 

•  Determine  if  an  entered.sensor_range,  madejsensor.contact,  or  a  collision-di¬ 
stance-reached  will  occur  prior  to  the  next  preplanned  event  location. 

-  If  a  sensor(s)  contact  is  found,  schedule  the  earliest  event. 

-  If  no  contact  is  found,  schedule  the  next  preplanned  event  from  the  vehi¬ 
cle’s  route-data. 

Move:  Objects  move  through  the  system  based  on  information  known  at  the 
start  of  the  scenario  (the  route  data),  and  reactions  to  situations  (threats  or  obsta¬ 
cles).  Each  vehicle  object  has,  as  part  of  its  attributes,  route  data  for  the  current 
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scenario.  The  route  data  contains  the  locations  of  all  known  events  for  that  vehicle. 
A  typical  set  of  route  data  will  include  the  location  of  all  turnpoints  and  targets.  Ide¬ 
ally,  events  are  scheduled  which  coincide  with  a  vehicle  moving  through  turnpoints 
and  targets,  eventually  arriving  at  the  vehicle’s  destination.  Realistically,  vehicles 
can  encounter  threats,  either  ground-based  or  from  another  vehicle,  or  obstacles 
which  may  add  additional  turnpoints  to  the  preplanned  route.  Thus  the  basic  model 
for  move  is  iteratively  perceive  -  move  (based  on  perceived  data)  -  perceive. 

Fight:  Objects  from  opposing  sides  may  fight  if  the  following  conditions  are 

met: 

•  One  or  more  of  the  objects  is  aware  of  (perceives)  another  object. 

•  One  or  more  of  the  objects  is  within  range  of  the  type  of  weapon  the  perceiving 

object  is  equipped  with. 

•  The  perceiving  object  has  not  previously  exhausted  its  armament  store. 

Vehicles  reaching  a  predetermined  target  will  attack  it.  Vehicles  encountering 
enemy  vehicles  or  stationary  objects  from  an  opposing  side  may  attack  based  on 
whether  they  have  extra  ordnance  allowing  them  to  do  so,  the  probability  of  enemy 
destruction  versus  their  own,  and  whether  undetected  avoidance  is  possible. 

3.4  Low  Level  Design 

This  section  details  object  attributes  and  the  functions  which  support  the 
occurrence  of  events.  The  object  structures  used  in  this  simulation  are  in  the  file 
simjstru.h.  The  code  for  the  functions  used  in  this  simulation  is  in  sim_func.h  and 
sim_func.c.  These  files  are  listed  in  Appendix  A. 

3.4 -1  Object  Attributes  The  basic  construction  of  the  objects  are  as  C 
structures  where  the  object’s  attributes  are  components  of  the  structure.  Some  of 
the  attributes  themselves  may  also  be  structures  containing  additional  information. 
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Thus  some  nesting  of  the  structures  will  take  place.  Figure  3.4  shows  the  relationship 
of  objects  to  attributes. 

The  first  object  types  are  those  instantiated  through  the  use  of  the  object_attri- 
butes  structure.  Object-attributes  can  be  instantiated  to  create  a  myriad  of  different 
types  of  objects  as  well  as  creating  the  same  basic  type  with  differing  characteristics. 
A  quick  glance  at  the  current  attributes  of  this  structure  may  lead  one  to  believe 
that  this  structure  is  used  to  instantiate  only  moving  objects,  since  the  structure 
attributes  include  velocities,  rotation  rates,  etc....  However,  moving  objects  are  only 
a  subset  of  the  total  item  types  that  can  be  instantiated  using  the  object-attributes 
structure.  By  simply  initializing  to  zero  those  attributes  which  are  not  applicable, 
the  set  of  non-moving  objects  can  also  be  created  using  this  structure. 

Creating  objects  through  instantiation  of  a  structure  is  an  excellent  way  to 
ensure  ease  of  modification  and  growth  of  this  simulation  code.  This  is  because  in¬ 
formation  for  new  or  more  complex  manipulation  of  the  objects  within  the  simulation 
can  easily  be  incorporated  by  simply  adding  the  required  attribute  to  the  already 
existing  structure.  Below  is  a  brief  explanation  of  the  current  attributes  making  up 
object_attibutes. 

Attribute  Explanations 

int  object-type:  Used  as  an  icon  identifier  for  the  display  system 

int  object-id:  Integer  value  used  as  a  object  identifier. 

int  object Joyalty:  Integer  value  indicating  loyalty. 

double  current-time:  The  time  of  the  most  recent  event  for  the  object. 

int  fuel-status:  Integer  value  denoting  the  current  available  fuel. 

int  condition:  Integer  value  indicating  the  object’s  current  condition.  Values  are 

between  0  and  100,  0  being  destroyed,  100  being  fully  operational. 

int  vulnerability:  Integer  value  indicating  the  destructive  force  needed  to  destroy 

the  object. 

struct  location-type  location:  A  structure  containing  the  current  location  of  the 
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object. 

struct  xyz_velocities:  A  structure  containing  the  velocity  vectors  (i>x,  vy,  vz)  oi' 
the  object. 

struct  orientation-type  orientation:  A  structure  containing  the  current  orien¬ 
tation  of  the  object. 

struct  rotation-rates:  A  structure  containing  the  rotation  rates  around  the  x,  y, 
and  z  axis. 

struct  operator-type  operator:  A  structure  containing  the  operator’s  qualities 
such  as  experience  and  threat  knowledge. 

struct  performance-characteristics  performance:  A  structure  containing  the 
performance  characteristics  of  the  object  such  as  the  minimum  turning  radius,  max 
speed,  max  climb  rate,  and  average  fuel  consumption. 

struct  linkedJist*  sensors:  A  pointer  to  a  linked  list  which  contains  the  informa¬ 
tion  about  the  sensors  the  object  has  available  to  it. 

struct  linkedJist*  armaments:  A  pointer  to  a  linked  list  which  contains  the  in¬ 
formation  about  the  armaments  the  object  has  available  to  it. 
struct  linkedJist*  defensive-systems:  A  pointer  to  a  linked  list  which  contains 
tiie  information  about  the  defensive-systems  the  object  has  available  to  it. 
struct  linkedJist*  route.data:  A  pointer  to  a  linked  list  which  contains  the  rout¬ 
ing  information  for  the  current  scenario. 

struct  linkedJist*  target -list:  A  pointer  to  a  linked  list  which  contains  informa¬ 
tion  about  a  object’s  target(s). 


The  second  object,  operator-type,  is  a  structure  containing  information  about 
the  operator’s  experience  and  knowledge  of  the  threat.  These  are  two  items  which 
are  critical  to  the  successful  outcome  of  most  confrontations.  This  object  is  not 
being  utilized  in  any  of  the  current  simulation  algorithms,  most  notably,  the  at¬ 
tack  sequence  algorithm;  However,  this  “hook”  was  deliberately  put  in  so  that  this 
information  could  be  incorporated  at  a  later  date  to  enhance  the  realism  of  the 
simulation. 

At  this  time  the  operator-type  contains  the  following  attributes,  but  of  course 
it  can  be  expanded  if  other  information  becomes  necessary. 

Attribute  Explanations 

int.  experience:  An  integer  value  attributable  to  the  operator’s  experience  level, 
iiit  threat.knowledge:  An  integer  value  attributable  to  the  operator’s  knowledge 
of  a  particular  type  of  threat. 

Object  three  is  the  performance-characteristics  object.  This  object  is  basically 
another  hook.  It  contains  some  limiting  performance  factors  which  could  easily  be 
used  to  determine  current  fuel  status,  and  whether  certain  maneuvers  are  possi¬ 
ble.  Here,  too,  more  information  may  eventually  be  incorporated  depending  on  how 
detailed  performance  is  modelled. 

Attribute  Explanations 

int  min-turn_radius:  An  integer  value  giving  the  minimum  turning  radius  of  the 
vehicle. 

int  mux.speed:  An  integer  value  indicating  the  maximum  speed  the  vehicle  could 
travel. 

ave.fuel_cons_rate:  A  rate  indicating  how  fast  the  vehicle’s  fuel  is  being  consumed, 
int  max_climb_rate:  A  rate  indicating  how  fast  a  vehicle  could  climb  (if  applica¬ 
ble). 
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resolution 


note:  The  list!  are 


linked  lists  of  items 
containing  the  attributes  shown. 


linked  list 


Figure  3.4.  Object  Attribute  Relationships 
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Object  four  is  a  linked  list  containing  the  the  route  points  for  each  object. 
Every  object  has  its  own  route  data  linked  list.  Even  stationary  objects  will  have  a 
route  data  linked  list.  The  stationary  object  linked  list  will  contain  only  one  point, 
it  will  match  the  objects  current  position  and  will  be  used  to  establish  the  object’s 
position  on  the  display. 

Attribute  Explanations 

struct  location.type:  Structures  which  are  the  x,  y,  and  z,  coordinates  of  the 
object’s  route  points. 

Sensors  are  object  five.  Each  object  can  have  a  finked  fist  containing  the  sensors 
available  to  that  object.  The  attributes  are  self  explanatory.  The  default  value  ol' 
the  function  get_sensor_range,  if  there  are  no  sensors  in  an  object’s  sensor  linked 
list,  is  833  meters,  approximately  a  half  mile.  The  algorithm  for  sensor  selection  is 
presented  in  the  algorithm  discussion  section. 

Attribute  Explanations 

int  type:  The  integer  value  which  represents  a  particular  sensor  such  as  radar  =  1. 
eye  =  2  ... 

int  range:  The  integer  detection  range  of  the  sensor. 

int  resolution:  The  integer  factor  which  indicates  how  clearly  an  object  is  seen 
once  detected. 

Armaments  are  object  six.  Each  object  may  have  a  linked  fist  of  armaments 
containing  the  armaments  which  are  available  for  use  by  the  object.  This  object  has 
a  wealth  of  information  which  can  be  used  to  add  to  the  realism  of  the  simulation. 
Currently  this  object  is  not  being  used,  but  further  incorporation  of  the  data  con¬ 
tained  within  this  object  is  straightforward.  For  instance,  the  count  attribute  could 
be  checked  and  decremented  as  necessary,  before  a  shot  could  be  allowed. 
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Attribute  Explanations 

int  type:  The  integer  values  which  represent  a  particular  type  of  armament, 
int  range:  Integer  value  of  the  range  of  the  armament. 

int  lethality:  Integer  value  of  the  destructive  power  of  the  armament.  Used  to 
determine  condition  of  vehicle  or  stationary  object  based  on  its  vulnerability  value, 
accuracy:  Integer  value  of  the  accuracy  of  the  armament, 
count:  How  many  of  a  particular  type  of  ordinance  are  available  or  left. 


Object  seven,  the  defensive-systems,  are  similar  in  use  to  sensors.  Each  object 
may  have  defensive  systems  which  could  be  used  to  affect  the  outcome  of  a  confronta¬ 
tion.  Using  this  information  could  add  to  the  realism  of  the  simulation.  However, 
at  this  time  this  area  has  been  left  unaddressed.  Attributes  could  be  added  to  those 
shown  below  if  necessary. 

Attribute  Explanations 

int  type:  The  integer  values  which  represents  a  particular  type  of  defensive-system 

such  as  chaff  =  1,  flares  =  2,  jammer  =  3. 

int  range:  Integer  value  of  the  range  of  the  defensive-system. 

int  effectiveness:  An  integer  representation  of  the  defensive  system  effectiveness. 


The  target-list  is  object  eight.  Each  object  should  have  a  target  list  to  help 
determine  who  the  “bad  guys”  are.  The  absence  of  a  target  list  does  not  mean 
that  an  object  has  no  enemies,  since  a  difference  in  the  object  -loyalty  attribute  will 
indicate  whether  an  encountered  object  is  on  the  same  side  or  not.  Objects  without 
targets  will  evade  other  objects  without  the  same  loyalty  if  possible.  The  usage  of 
the  target-list  is  explained  in  the  algorithm  discussion  section. 

Attribute  Explanations 

int  target-type:  The  integer  value  which  represents  the  type  of  the  target  (i.e. 
FI 5,  MIG,  TANK  ...). 
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struct  location.type:  Contains  the  expected  location  of  the  target. 


3.4-2  Supporting  Functions  This  section  gives  a  verbal  description  of  the 
functions  used  to  carry  out  the  effects  of  event  occurrences.  Object  attributes  may 
need  to  be  updated,  current  and  future  scenario  states  may  need  to  be  evaluated, 
and  decisions  may  need  to  be  made.  Tables  3.3  and  3.4  shows  what  functions  are 
used  in  support  of  the  events  possible  using  this  simulation  software. 

Function:  add_event_coords_to_route 

Verbal  Description:  Add.event.coords.to.route  uses  add_new_routepoint  to  add 
a  new  routepoint  to  both  objects  passed  as  the  argument  to  this  function. 

Function:  add-new  .routepoint 

Verbal  Description:  Add_new_routepoint  puts  a  new  turnpoint  into  the  route  data 
linked  list.  The  new'  turnpoint  becomes  the  next  prescheduled  routepoint. 

Function:  attack 

Verbal  Description:  Attack  creates  a  “missile”  (an  instance  of  object-attributes). 
Attack  initializes  the  location  of  the  missile,  gives  it  a  velocity,  creates  and  inserts 
three  routepoints  into  the  missile’s  route  data  linked  list.  A  pointer  to  the  missile  is 
then  put  into  the  master.objJist,  and  a  release-ordnance  event  is  scheduled. 

Function:  calc.curr.orientation 

Verbal  Description:  Calc.curr.orientation  calculates  the  current  orientation  of  an 
object  based  on  its  current  location  and  its  next  position  from  its  route  data. 
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Events 

Supporting  Functions 

Supporting  Supporting  Functions 

reached.turnpoint 

update.position 

calc.curr.orientation  ! 

calc.curr.velocities 
update.object_current.time 
send.fupdate 

sensor.check 

calc.timejit.next  j-outept 
get.sensor  .range 
calc.time-at.nextnext.routept. 
line.of-sight 
difference  Jn.altitude 
add.event.coords.to.route 
add.new.routepoint 

entered-sensor.range 

update.position 

calc_curr  .orientation 
calc.curr.velocities 
update.object.current.time 
send.fupdate 

sensor_check 

caic_time_at_next_routept 
get.sensor  .range 
calc.time_at.next  next. routept 
line.of.siglit 
difference  jn.alti  tude 
add.event.coords.to.route 
add.new.routepoint 

made^ensor-contact 

update.position 

calc.curr.orientation 

calc.curr.velocities 

update.object.current.time 

send.fupdate 

operator-evaluation 

get.sensor.range 

evade 

attack 

sensor.check 

calc_time_at_next_routept 

get.sensor.range 

calc.time^t.nextnext.routept 

linc.of.sight 

differenceJn.altitude 

add..event_coords_to_roui.e 

add.new.routepoint 

Table  3.3.  Events  and  Supporting  Functions 
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Function:  calc.curr.  velocities 

Verbal  Description:  Calc.curr  .velocities  calculates  the  current  velocity  vectors 
based  on  its  current  total  horizontal  velocity,  and  its  next  position  from  the  object’s 
route  data. 

Function:  calc_time_at_next_routept 

Verbal  Description:  Calc_time_at_next_routept  calculates  the  time  at  the  next 
rcutepoint  based  on  its  current  position  the  distance  to  the  next  position  and  the 
total  velocity  vector. 

Function:  calc_time.at_nextnext_routept 

Verbal  Description:  Calc_time_at_nextnext_routept  calculates  the  time  at  the 
routepoint  after  the  next  routepoint  based  on  its  current  position  the  total  distance 
to  the  final  position  and  the  total  velocity  vector. 

Function:  damage.assessment 

Verbal  Description:  The  eventual  function  of  damage_assessment  is  to  determine 
the  amount  of  damage  an  object  has  sustained  based  on  vulnerability,  current  con¬ 
dition,  and  what  ordnance  was  used.  If  total  destruction  has  occurred,  then  call 
tevminate.objects.  The  current  implementation  of  this  function  assesses  all  damage 
to  be  total. 

Function:  difference Jn_altitude 

Verbal  Description:  DifFerence_in_altitude  uses  the  objects  current  positions,  their 
z  velocity  vectors,  and  the  time  to  the  next  event  to  determine  if  the  objects  will  bo 
at  the  same  altitude  at  the  next  event  time. 

Function:  evade 

Verbal  Description:  Evade  modifies  the  current  velocity,  and  orientation  of  the 
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object  in  question.  Evade  also  adds  a  new  routepoint  to  the  object’s  route  data  and 
sends  the  updated  poition  information  to  the  display  driver. 

Function:  hit_miss 

Verbal  Description:  Hit_miss  determines  whether  the  target  was  hit  or  missed. 
This  could  be  based  on  factors  such  as  range,  ordnance  accuracy,  and  defensive 
systems  used,  as  well  as  whether  the  ordnance  and  target  are  occupying  the  same 
or  nearly  same  location.  The  current  implementation  of  this  function  determines 
hit_miss  solely  by  location  of  the  ordnance  and  target.  If  a  hit  has  been  determined, 
damage_assessment  is  called. 

Function:  line.oLsight 

Verbal  Description:  The  intent  of  the  line.oLsight  function  is  to  check  to  sec 
whether  a  clear  (unobstructed)  line  of  sight  exists  between  two  objects.  Obstructions 
may  be  caused  by  the  terrain  or  possibly  atmospheric  phenomena.  However,  this 
algorithm  remains  unimplemented,  due  in  the  most  part  to  the  fact  that  terrain  has 
not  yet  been  modelled.  The  function  exists  as  another  “hook”,  and  currently  returns 
true  (a  valid  LOS  exists)  for  all  cases. 

Function:  on.collision.course 

Verbal  Description:  On.collision.course  determines  whether  two  objects  are  on  a 
collision  course.  The  return  value  is  true  or  false.  The  primary  use  of  this  function 
is  when  two  objects  of  the  same  loyalty  encounter  each  other.  Since  they  are  on  the 
same  side  they  don’t  need  to  take  any  action  (i.e.  attack,  or  evade),  unless  they  are 
on  a  “collision  course”. 
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Events 

Supporting  Functions  Supporting  Supporting  Functions 

ordnance_released 

update.position 

calc_curr_orientation 
calc.car  r.veloci  ties 
update..object-current_time 
send.fupdate 

sensor.check 

calc_time.At..next-routept 
get-sensor.range 
calc_time-at.nextnext._i'outepi 
line.of-sight 
difference-in.altitude 
add_event-coords-to.route 
add.new_rout.epoi  n( 

ordnance_reached_target 

update.position 

calc.cuiT  .orientation 
calc-Curr-velociti<'s 
update_object_current_t  i  me 
send.fupdate 

add.new -routepoint. 
hit_miss 

1 

eollision_distance_reachcd 

update.position 

calc.curr  .orientation 
calc..curr_vclocit  ies 
update-object-current-time 
send.fupdate 

damage-assessment 

Table  3.4.  Events  and  Supporting  Functions 
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Function:  on-target-list 

Verbal  Description:  The  purpose  of  on.target.iist  is  to  determine  whether  a  threat 
encountered  by  an  object  is  an  actual  target  of  the  perceiving  object.  The  function 
will  return  true  if  the  threat  is  an  actual  target.  The  determination  algorithm  used 
is  explained  in  the  algorithm  discussion  section. 

Function:  operator-evaluation 

Verbal  Description:  The  basic  function  of  operator.evaluation  is  to  evaluate  the 
threat  and  choose  a  course  of  action.  Evaluation  of  the  threat  may  be  in  the  form 
of  answering  questions  such  as:  is  the  threat  a  “bad  guy”,  is  the  threat  the  intended 
target.,  and  if  it  is  a  friend,  are  we  on  a  collision  course?  Courses  of  action  could  In' 
attack,  evade,  or  do  nothing. 

Function;  read.data.file 

Verbal  Description:  The  read_data.file  function  is  used  to  read  in  the  initial  object 
data  from  an  ASCII  file.  The  format  for  this  file  is  shown  in  Figure  3.5.  Important: 
Fields  are  separated  by  a  single  blank  space,  after  all  required  fields  are 
entered  for  an  object  (i.e.  an  F-15)  a  C  compatible  End-of-Line  (EOL)  is 
entered. 

Function:  send.fupdate 

Verbal  Description:  The  send.fupdate  function  is  used  to  send  formatted  object 
updates  to  a  datafile  which  is  to  be  read  by  a  generic  display  driver.  See  Appendix 
D  for  format  and  interface  requirements  of  the  generic  diplay  driver. 
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field  1 

field  2 

field  3 

field  4 

field  5 

field  0 

int 

int 

iut 

double 

int 

int 

int 

object  id 

fuel  *tat 

condition 

field  8 

field  9 

field  10 

field  12 

field  13 

field  M 

double 

double 

double 

double 

double 

double 

double 

curr  x  coord 

curr  y  coord 

curr  z  coord 

x  velocity 

y  velocity 

z  velocity 

yaw  rule 

Reid  15 

field  16 

field  17 

field  18 

field  19 

field  20 

field  21 

double 

double 

ini 

int 

int 

int 

int 

pitch  rate 

roll  rate 

experience 

threat  know 

nun  turn  rad 

max  speed 

live  find  rr»nv 

field  22 

field  23 

field  2d 

field  25 

field  26 

field  27 

field  2.S 

int 

iut 

double 

double 

double 

int 

int 

max  climb 

#  roulepu 

x  coord 

y  coord 

z  coord 

#  sensors 

sensor  t y  | m ’ 

f  run  In-  n  |»-.'l r. I 


field  29  field  .10  field  31 


iut  iut  1  int 


sensor  range  tensor  resolution!  #  armaments 


#  sensor  times 


field  32 


int 


arm  type 


field  31 

field  35 

int 

ini 

arm  ycild 

arm  accm.it  \ 

field  33 


int 


can  be  repeated  #  armament  times 


Figure  3.5.  Input  File  Format 


Function:  sensor.check 

Verbal  Description:  Sensor.check  compares  a  object’s  projected  sensor  zone  path 
with  all  other  sensor  zone  paths  and  positions  of  stationary  sensor  zones  within 
the  system  to  determine  if  the  object’s  sensor  will  pick  up  anything  before  its  next 
predetermined  scheduled  event.  In  order  for  a  sensor  to  be  able  to  “see”  another 
object  the  following  rules  should  be  satisfied: 

•  The  sensor  being  used  must  be  operational. 

•  The  object  to  be  detected  must  move  within  the  sensor’s  range. 

•  An  unobstructed  Line-Of-Sight  (LOS)  must  exist  between  the  sensor  and  the 
object  being  sensed.  An  unobstructed  LOS  is  dependent  in  part  on  which 
sensors  are  being  used. 

Five  different  events  can  be  scheduled  by  sensor.check  depending  on  what  is 
found  during  the  sensor.check  evaluation.  If  a  sensor  contact  is  found,  and  the  sensor 
range  of  both  objects  in  question  is  zero,  along  with  an  altitude  seperation  of  less 
then  five  meters,  a  collision_distance_reached  event  will  be  scheduled.  If  a  sensor 
contact  is  found  but  there  is  a  sensor  range  being  used  greater  then  zero  or  there 
is  a  difference  in  altitude,  then  either  an  entered  .sensor  .range,  madejsensor.contact, 
or  (in  the  case  where  the  object  is  a  missile)  an  ord n an ce_reached _t arget  will  be 
scheduled.  If  a  no  contact  is  found,  then  a  reached.turnpoint  event  is  scheduled  at 
the  appropriate  time.  The  algorithm  used  to  implement  this  function  is  detailed  in 
the  algorithm  discussion  section. 

Function:  terminate_objects 

Verbal  Description:  The  terminate_objects  function  sends  a  message  to  the  display 
file  indicating  that  an  object  need  not  be  displayed  any  longer.  It  deletes  all  currently 
scheduled  events  from  the  next  event  queue  involving  the  now  dead  object,  deletes 
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the  object  pointer  from  the  master_obj_list,  and  frees  the  memory  used  to  hold  the 
event_argument. 

Function:  update_object_current_time 

Verbal  Description:  Update_object.current-time  simply  assigns  the  event-time  to 
tl  :  object’s  current  time  attribute,  thus  updating  the  object  current  time  to  the 
current  event  time. 

Function:  update.position 

Verbal  Description:  Update_position  takes  the  next  route  point  from  the  route 
data  and  updates  the  current  location  of  the  object.  It  then  calls  in  this  order, 
calc_curr_orient,ation,  calc.curr.velocities,  update_object-current_time,  and  send_fup- 
date. 

3.5  The  Interfaces 

3.5. 1  Overall  System  Interface  In  keeping  with  the  modularity  and  object 
construction  design  scheme,  the  code  has  been  constructed  to  facilitate  modification 
and  growth.  The  overall  system  interfaces  are  illustrated  in  detail  in  Figure  3.G.  It 
shows  a  rather  complex  structure  which  makes  use  of  two  generic  C  packages,  the 
generic  simulation  package  (sim_driv.h  and  sim_driv.c)  and  the  generic  linked  list 
package  (11. h  and  11. c),  which  were  developed  in  a  separate  effort  and  are  given  in 
Appendix  C.  The  simulation  structures,  simulation  events,  supporting  simulation 
functions,  and  main  simulation  code  are  all  in  separate  files  and  are  provided  as 
Appendix  A.  The  only  other  interface  is  the  generic  display  driver  interface.  The 
generic  display  driver  was  a  separate,  but  concurrent  research  effort  (9).  The  interface 
requirements  are  provided  in  Appendix  D. 
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3.5.2  The  Driver  Interface  As  was  the  case  in  the  areas  discussed  pre¬ 
viously,  the  simulation  driver  was  approached  generically.  The  design  will  not  be 
covered  in  detail  here  since  it  was  completed  as  separate  work  and  is  given  in  Ap¬ 
pendix  C.  The  overall  function  of  the  driver  is  to  execute  the  simulation.  It  ac¬ 
complishes  this  through  the  use  of  the  functions  mate. driver,  schedule-event,  exe- 
cute.sim,  delete-event,  and  en<Lsim.  These  functions  are  all  available  to  the  user 
writing  an  event  driven  simulation  which  makes  use  of  a  NEQ. 

The  following  are  brief  explanations  of  the  functions  of  the  generic  simulation 
driver. 

make-driver:  The  make_driver  function  allows  the  user  to  create  an  instance 
of  the  simulation  driver.  The  user  can  then  use  the  other  simulation  driver  functions 
available  to  manipulate  the  the  driver  in  creating  a  working  simulation.  A  compari¬ 
son  function  is  supplied  by  the  user  to  the  driver  to  allow  the  driver  to  properly  sort 
events. 

schedule_event:  The  schedule-event  function  allows  the  user  to  schedule 
events  by  passing  a  pointer  to  the  event  function,  its  arguments,  and  the  time  of 
the  event  with  the  simulation  identifier  ’driver’. 

execute_sim:  The  execute.sim  function  executes  the  functions(events)  which 
have  been  scheduled  with  the  schedule-event  function.  Executejsim  will  continue 
dispatching  events  until  there  are  no  more  events  scheduled  in  the  NEQ. 

delete-event:  The  delete.event  function  gives  the  user  the  ability  to  remove 
previously  scheduled  events  from  the  NEQ.  Using  the  event-id,  returned  to  the  user 
when  using  “schedule-event”,  delete.event  searches  for  a  matching  event  id  in  the 
NEQ  and  deletes  it. 

end_sim:  The  end-sim  function  gives  the  user  the  ability  to  stop  the  simula¬ 
tion.  End-sim  effectively  empties  the  NEQ. 
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IV.  MAJOR  ALGORITHM  DISCUSSIONS  AND 
IMPLEMENTATIONS 


The  following  sections  highlight  the  major  algorithms  used  in  the  simulation 
implemented  as  part  of  this  thesis  work.  Although  each  function  has  an  associ¬ 
ated  algorithm  only  those  deemed  in  need  of  a  more  detailed  explanation  are  given 
here.  These  algorithms  represent  the  more  complex  or  more  interesting  algorithms 
of  the  simulation  code.  These  algorithms  are  simply  one  way  to  model  these  func¬ 
tions.  They  could,  and  possibly  should,  be  modified  to  create  more  realism  in  the 
simulation. 

J,.l  The  Evade  Algorithm 

The  basic  high  level  algorithm  employed  is  straightforward.  However  its  im¬ 
plementation  is  considerably  more  complex  due  to  the  number  of  special  cases  which 
exist.  The  basic  algorithm  states: 

-  Calculate  or  determine  the  threat  object’s  path. 

-  Calculate  and  adjust  the  evading  object’s  orientation  and  velocity  vectors  such  thal  llie 
new  direction  is  90  degrees  from  the  threat  path,  moving  away  from  the  threat  path. 

-  Calculate  a  new  routepoint  for  the  evading  object,  given  the  evading  object’s  now 
orientation  and  velocity  vectors. 

-  Add  the  new  routepoint  to  the  evading  object’s  route  data. 


There  are  three  special  cases  which  must  be  handled  separately  due  to  the 
usage  of  trigonometric  functions  and  divide  by  zero  problems. 
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•  Case  I:  When  the  x  velocity  vector  of  the  object  to  be  evaded  equals  zero, 
and  the  y  velocity  of  the  object  to  be  evaded  is  not  equal  to  zero.  This  is 
the  situation  in  two  dimensions  where  the  object  to  be  evaded  is  moving  on 
a  path  which  is  parallel  to  the  y  axis.  If  this  situation  exists,  then  according 
to  the  algorithm,  the  direction  of  evasion  will  be  along  a  path  parallel  to  the 
x  axis.  What  now  must  be  established  is  whether  the  movement  will  be  in 
the  positive  x  direction  or  the  negative  x  direction.  This  is  established  by 
simply  evaluating  the  difference  between  the  x  coordinates  of  the  two  objects. 
Once  the  direction  is  known,  the  total  velocity  vector  is  then  applied  to  that 
direction.  This  situation  is  illustrated  in  Figure  4.1. 


Figure  4.1.  CASE  I:  x  velocity  vector  —  0,  y  velocity  vector  ^  0 
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•  Case  II:  Case  II  is  just  the  opposite  of  Case  I.  Here  the  x  velocity  vector  of  the 
object  to  be  evaded  is  not  equal  to  zero  and  the  y  velocity  vector  is  equal  to 
zero.  Handling  this  situation  is  logically  identical  to  Case  I  so  it  need  not  be 
detailed  again.  This  situation  is  illustrated  in  Figure  4.2. 


Figure  4.2.  CASE  II:  x  velocity  vector  /  0,  y  velocity  vector  =  0 
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•  Case  III:  Case  III  is  slightly  more  tricky.  In  Case  III  both  the  x  and  y  velocity 
vectors  of  the  object  to  be  evaded  are  zero.  This  means  that  the  object  to  be 
evaded  is  stationary,  and  as  a  consequence  will  also  not  be  eventually  moving 
out  of  the  path  of  the  other  object.  So  how  then  does  the  evading  object  get 
by  the  object  to  be  evaded?  The  algorithm  for  this  situation  is  as  follows  and 
is  illustrated  in  Figure  4.3: 


evading  object 
next  routepoint 


Figure  4.3.  CASE  III:  x  velocity  vector  =  0,  y  velocity  vector  =  0 
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-  Draw  a  line  between  the  current  locations  of  the  two  objects  and  calculate 
the  slope  of  this  line. 

-  Calculate  two  new  locations.  Each  location  should  be  an  equal  distance 
and  on  opposite  sides  of  the  evading  object  along  a  line  which  is  DO  degrees 
from  the  line  found  in  step  one. 

-  Now,  compare  the  distances  from  each  new  point  to  the  evading  object’s 
next  routepoint.  The  shorter  of  the  two  distances  indicates  the  proper 
direction  for  the  evading  object  to  turn. 

-  Add  the  new  routepoint  to  the  evading  object’s  route  data. 

-  Calculate  the  current  orientation  of  the  evading  object. 

There  is  one  special  case  within  this  case  which  also  warrants  mentioning.  This 
situation  occurs  when  an  object’s  next  preplanned  routepoint  is  within  its  own 
sensor  range  of  the  object  it  is  trying  to  evade.  When  this  occurs,  the  evading 
object  would,  after  moving  to  an  intermediate  evasion  point,  try  to  return  to 
its  next  preplanned  routepoint  which  it  could  never  get  to,  since  evade  would 
simply  be  called  over  and  over  again.  Thus,  the  way  this  is  handled  is  that 
before  the  evasion  point  is  calculated  and  loaded  into  the  evading  object’s  rout  o 
data,  the  next  preplanned  routepoint  is  checked  to  see  if  it  is  usable  (not  too 
close  to  the  object  to  be  evaded).  If  it  is  too  close  to  the  object  to  be  evaded, 
then  that  point  is  discarded  and  the  next  preplanned  routepoint  takes  its  place. 
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In  the  general  case,  both  objects  are  moving  and  the  object  to  be  evaded  is 
not  moving  in  a  path  parallel  to  any  axis.  The  algorithm  for  this  case  is  as  follows: 

•  Calculate  the  slope  of  the  object  to  be  evaded  using  its  x  and  y  velocity  vectors. 

-  Assign  the  negative  inverse  of  this  slope  to  the  slope  of  the  evading  object. 

-  Using  the  standard  equation  of  a  line,  y  =  mx  -f  6,  calculate  the  y 
intercepts  of  both  lines. 

-  Simultaneously  solve  both  equations  for  a  common  x  and  y  coordinate. 

-  The  difference  between  the  common  x  and  v  coordinates  and  the  current 
x  and  y  coordinates  of  the  evading  object  indicates  the  proper  sign  of  the 
x  and  y  velocity  vectors  of  the  evading  object. 

-  Calculate  the  slope  angle,  atan  (evader  slope). 

-  The  magnitude  of  the  x  and  y  velocity  vectors  of  the  evading  object  will 
be  the  absolute  value  of  the  total  velocity  vector  times,  the  cosine  of  the 
slope  angle  and  the  sine  of  the  slope  angle  respectively. 

This  algorithm  is  illustrated  in  Figure  4.4. 
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Figure  4.4,  GENERAL  CASE:  x  velocity  vector  ^  0,  y  velocity  vector  ^  0 


4.2  The  Sensor  Check  Algorithm 

The  sensor.check  routine  creates  the  majority  of  the  workload  for  the  hardware 
running  the  simulation.  This  is  because  every  time  the  sensor.check  routine  is  called, 
every  object  in  the  simulation  scenario  must  be  interrogated.  Although  this  routine 
creates  a  large  workload,  it  does  not  necessarily  mean  it  is  the  most  complex  of  the 
algorithms  used  in  this  simulation  software.  Indeed,  the  high  level  algorithm  is  easily 
understood. 

-  Before  scheduling  an  object’s  next  preplanned  event,  determine  if 
there  are  any  other  events  which  should  take  place  prior  to  the 
preplanned  event;  schedule  the  earliest  event. 


At.  the  heart  of  this  algorithm  is  the  quadratic  equation  (31).  Specifically,  it 
is  t  he  solution  of  the  quadratic  equation  in  (/.)  which  yields  the  sought  after  time  at 
which  two  objects  will  come  within  a  given  distance  (d)  of  each  other.  The  usage  of 
the  quadratic  equation  in  ( t )  is  illustrated  here.  If  two  moving  objects  have  a  current 
position  of  (a^,,  yatl)  and  y^,)  as  shown  in  Figure  4.5,  then  their  respective 

coordinates  at  future  time  ( t )  can  be  represented  by  the  following  equations: 


xa/  —  ^oii  d"  ^j) 
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yat  =  s/ad  +  iw,(*  -  <t) 


*bt  ~  Xklt  +  Vxkit(t  -  1 1) 


ybi  -  J/6t,  +--V|)Mi(<  -  <l) 


xa<  is  the  x  coordinate  of  object  “a”  at  some  time  t 
xat%  is  the  current  x  coordinate  of  object  “a”  at  time  ti 
uiatl  is  the  current  x  velocity  vector  of  object  “a”  at  time  1 1 
yat  is  the  y  coordinate  of  object  “a”  at  some  time  i 
yat ,  is  the  current  y  coordinate  of  object  “a’*  at  time  t \ 

Vyati  is  the  current  y  velocity  vector  of  object  “a’*  at  time  t\ 
This  assumes  v  does  not  change  between  t  and  t\ 
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Now  if  we  let:  xah  —  XA  and  vxati  -  Vxa  and  yati  =  VA  and  tylt,  -  VyA 
etc.  and  A<  =  t  —  <1  (the  time  until  the  event  will  occur,  e.g.  if  At  is  5,  then  the 
event  will  occur  in  five  time  units  from  the  current  time).  Then 

z'nt  -  xbt  =  (XA  +  VxaA t)  -  (A'b  +  VxB&t)  =  (XA  -  XB)  +  (VXA  -  VXbW 


Making  similar  substitutions  for  the  y  coordinates  yield 

yat  -  y*  =  (Ya  -  Yb)  +  (VYA  -  VVB) At 

According  to  the  distance  formula:  d(t)  —  n,  )2  4-  (j/„,  - 

Making  the  substitutions  into  the  distance  formula  yield: 

((-V,,  -  XH)  +  (Vxa  -  Vx^At)2  +  ((YA  -  VB)  +  (VYA  ~  Vyh)AI)‘  =  </' 

For  clarity  let,  /  =  (XA  -  XB),  m  =  ( Vx A  ~  VXB),  n  -  (V,»  -  V'c),  and 
V  -  ('V/»  --  Vyb  ).  Putting  it  into  the  form  of  the  quadratic  equation  yields: 

(m2  4-  p2)At2  +  (2/?7i  4-  2 np)At  +  (/2  4-  n2)  —  d2  ~  0 

—  (2/m  4-  2 np)  ±  \f(2lm  4-  2n;>)2  —  4(rn2  4-  pl)(/2  4-  «2  -  <P) 

A(  =  _____ 

The  distance  (d)  can  be  varied  according  to  the  range  of  the  sensor  being  used 
by  the  objects  in  question.  It  should  be  noted  here  that  this  application  of  the 
quadratic  equation  is  in  only  two  dimensions,  thus  the  sensor  zones  of  any  object 
appear  as  a  cylinder  that  knows  no  bounds  in  the  z  direction  as  shown  in  Figure  -1.6. 
Non-imaginary  solutions  to  the  quadratic  are  contact  points,  assuming  the  objects 
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actually  progress  along  their  current  routes  without  change.  Imaginary  solutions 
indicate  that  an  object  will  not  intersect  another  object’s  sensor  zones  ,  or  the  object 
is  already  within  the  sensor  zone  area  of  the  other  object.  The  two  solutions  that 
can  be  found  are  the  time  at  which  the  an  object  encounters  a  zone  and  the  time 
at  which  an  object  exits  a  zone.  This  implementation  of  scnsor.chcck  uses  only  the 
first  solution,  the  time  entering  the  zone. 


Figure  4.6.  Illustration  of  Object  Sensor  Zone 

The  actual  implementation  is  not  as  straightforward  as  the  original  algorithm 
implies.  The  implementation  algorithm  follows. 
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-For  all  moving  objects 

-For  as  many  objects  as  there  are  in  the  master^objJist 

-While  the  popped  object's  id  is  not  =  to  the  current  object  id 

-Calculate  the  term  under  the  radical  of  the  quadratic  equation  solution 
using  both  the  current  object's  and  the  popped  object's  sensor  range 

-Calculate  the  time  the  popped  object  wilt  reach  its  next  preplanned  event 
-If  term  under  radical  in  solution  is  >=  0  using  the  current  object's  sensor  range 
-Calculate  the  sensor  contact  timel  (the  quadratic  equation  solution) 

-If  the  sensor  contact  time  is  <  the  event  time  and  >  the  current  time 
and  <=  the  time  of  the  other  object’s  next  scheduled  event,  and  <  —  the  time 
of  its  own  next  preplanned  event,  and  a  line  of  sight  exists  between  objects. 
-Set  the  valid-contact  I  flag  to  TRUE 

-If  the  term  under  the  radical  >=  tero  using  the  other  object’s  sensor  range 
•Calculate  the  tensor  contact  time2  (the  quadratic  equation  solution) 

-If  the  sensor  contact  time  is  <  the  event  time  and  >  the  current  time  and 
<=  the  time  of  the  other  object’s  next  scheduled  event,  and  <=-.  the  time  of 
its  own  next  preplanned  event,  and  a  line  of  sight  exists  between  objects. 

-Set  the  valid.cantact2  flag  to  TRUE 
-If  valid  rontactl  or  valicl.contact2  are  TRUE 

-Set  the  appropriate  contact  flag(s)  to  TRUE  or  FALSE 

-end  for 

•  end  for 

•  If  contact  1  and  contact2  arc  TRUE,  and  sensing  range  =  0,  and  difference  in  altitndc  =  0 

-Schedule  a  collision  event 
■  Else  if  cent  act  1  or  contact2  is  TRUE 

-Add  the  appropriate  routepoints  to  the  current  object's  route  data 
-If  contacl2  is  TRUE 

•Schedule  an  entered -Sensor-range  event 
-If  contact)  is  TRUE  and  the  current  object  is  not  a  missile 
-Schedule  a  made  sensor  contact  event 
-if  contact  I  i»  TRUE  and  the  current  object  is  a  missile 
•  Schedule  an  ordnance-reaclied.targel  event 

-Else 

-Schedule  a  reached jtumpoint  event  for  the  current  object 


The  Operator  Evaluation  Algorithm 

The  operator-evaluation  algorithm  is  a  very  sim 
nates  in  a  course  of  action,  either  do  nothing,  evade, 
tree  is  depicted  in  Figure  4.7. 


pie  decision  tree  which  culmi- 
or  attack.  The  basic  decision 
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Although  rudimentary,  this  algorithm  could  be  considered  a  very  simple  expert 
system  where  an  operator’s  thought  process  is  being  modelled.  The  possibilities  for 
expansion  to  this  algorithm  are  limitless. 

4-4  The  Attack  Algorithm 

The  attack  algorithm  says: 

Instantiate  a  MISSILE  object 
Initialize  the  MISSILE’S  attributes 
Determine  and  load  the  MISSILE’S  routepoints 
Fire  the  MISSILE 


The  approach  taken  in  determining  a  missile’s  route  was  to  give  each  missile 
t  hree  routepoints.  The  first  routepoint  for  the  missile  would  be  the  current  locat  ion 
of  the  object  from  which  it  is  being  launched.  The  second  routepoint,  will  be  the 
current  location  of  the  object  at  which  it  is  being  fired,  keeping  in  mind  that  a  moving 
target  will  continue  moving  from  its  current  location.  Thus,  a  third  routepoint  must 
be  included  if  the  missile  is  to  have  any  chance  of  hitting  its  target.  The  third 
routepoint  of  the  missile  is  set  to  the  target’s  next  scheduled  routepoint.  Therefore, 
although  not  occurring  often  unless  scripted  in  that  way,  a  target  object  can  "get 
away”  if  it  can  reach  its  next  routepoint  before  the  missile  catches  it.  In  the  event 
that  the  missile  does  not  catch  the  target,  the  missile  simply  dies  at  that  point. 

4-5  The  Update  Position  Algorithm 

The  update.position  algorithm  is  the  most  used  algorithm  in  this  simulation. 
It  is  used  in  conjunction  with  other  algorithms  in  every  event  in  this  simulation 
software.  The  code  for  this  algorithm  is  compact,  making  use  of  four  function  calls 
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from  within  update.position.  The  order  of  the  function  calls  is  critical  to  ensure 
calculated  values  are  correct.  The  algorithm  is  stated  here: 

Pop  the  next  position  from  the  object’s  route  data 

Assign  the  next  position  coordinates  to  the  current  position  coordinates 
Calculate  the  current  orientation  of  the  object 
Calculate  the  current  velocity  vectors  of  the  object 
Update  the  object’s  current  time 

Send  the  update  to  a  file  (or  directly  to  the  display  driver,  if  available) 
If  there  were  no  routepoints  left  on  the  list  and  the  object  was  a  MISSlbK 
Terminate  the  missile 


/.6  The  Add  New  Routepoint  Algorithm 

The  add.new.xoutepoint  algorithm  is  very  simple,  given  some  time  in  the  future 
at  which  the  object  is  to  arrive  at  the  new  point  (e.g.  add  a  new  routepoint  at  a 
lime  30  seconds  from  now).  Thus  the  algorithm  reads: 

To  the  current  x,  y,  and  z  coordinates,  add  the  time  to  the  new  rontepoinl 
multiplied  by  the  respective  velocity  vectors. 

Add  the  newly  calculated  point  to  the  object’s  route  data. 


For  example,  if  the  current  x,  y,  and  z  coordinates  were  100,  250,  and  1000, 
with  vx,  vy,  andvz  as  200,  200,  0,  then  new  route  point  x,  y,  and  z  coordinates  at  a 
time  15  c'':,onds  from  the  current  time  would  be,  100  +  (200)(15),  250  +  (200)(  1 5). 
and  100:  ,  v0)(15j. 

There  is  one  critical  factor  involved  in  the  determination  of  a  new  routepoint. 
That  fact  is,  the  object  must  have  its  velocity  vectors  properly  adjusted  to  reflect 
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the  new  direction  of  movement  before  the  new  routepoint  can  be  calculated.  Obvi¬ 
ously  this  must  be  so  since  using  the  wrong  velocity  vectors  will  yield  incorrect  new 
coordinate  values. 

The  Calculate  Current  Orientation  Algorithm 

The  calc.curr.orientation  algorithm  uses  standard  trigonometry  to  find  the 
angles  between  the  object’s  current  coordinates  and  the  object’s  next  routepoint. 
Thus  the  basic  algorithm  used  was: 

Pop  the  next  routepoint  from  the  object’s  route  data. 

Calculate  the  angles  between  the  two  points,  yaw  and  pitch 
(roll  is  not  calculated  in  this  implementation). 

Adjust  the  object’s  attributes  accordingly. 

Reinsert  the  popped  routepoint  into  the  object’s  route  data. 


/,.$  The  Calculate  Current  Velocities  Algorithm 

The  calc.curr.velocities  algorithm  uses  a  similar  approach  to  calc.curr .oriental ion 
although  the  trigonometry  is  slightly  more  involved.  The  algorithm  for  this  function 

is: 


Pop  the  next  routepoint  from  the  object’s  route  data. 

Calculate  the  total  horizontal  velocity  vector. 

Find  the  angle  between  the  current  location  and  the  next  routepoint 
location. 

Calculate  the  horizontal  distance  between  the  two  points. 

Using  the  distance  and  horizontal  velocity  vector,  calculate 
the  time  to  the  next  routepoint. 

Using  the  sine,  and  cosine  of  the  angle  found,  calculate  the  now 
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x  and  y  velocity  vectors. 

Using  the  delta  z  value  and  the  time  to  the  next  routepoint,  calculate' 
the  new  z  velocity  vector. 

Reinsert  the  popped  routepoint  into  the  object’s  route  data. 


J.9  Other  Algorithms 

The  following  algorithms  were  not  discussed  in  this  chapter  because  they  are 
believed  to  be  easily  enough  understood  through  their  respective  module  headers 
and  by  simply  stepping  through  the  actual  code.  The  actual  code  is  in  Appendix  A. 

send.fupdate 

calc_time.at_next_routept 

calc_time.at_nextnext_routept 

read-datafile 

terminate_vehicle 

get  jsensor  .range 

line_of_sight 

damage.assessment 

hit.vniss 

difference  Jn.altitude 
add_event_coords_to_route 
update.object_current  .time 
on.collision.course 
on.target.list 
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V.  RESULTS,  CONCLUSIONS,  RECOMMENDATIONS 


5. 1  Results,  Meeting  the  Objectives 

At  the  onset  of  this  thesis  effort,  time  was  spent  defining  basic  objectives  which 
needed  to  be  met.  These  objectives  were  found,  of  course,  to  be  driven  by  the  planned 
usage  of  the  final  product.  That  plan  was  to  parallelize  the  simulation  code  created 
by  this  thesis  and  to  use  the  parallel  version  in  speedup  studies  concerning  military 
simulation  executions  on  parallel  computers.  Thus  the  following  were  the  objectives 
defined: 

1.  Create  a  military  scenario  simulation  using  a  modular  object-oriented  design. 

2.  Use  the  C  programming  language. 

3.  The  final  product  must  be  easily  modified. 

4.  The  final  product  should  exhibit  a  high  degree  of  computational  complexity. 

5.  The  simulation  code  should  be  generic  in  nature  such  that,  differing  scenarios 
could  be  run  simply  by  altering  the  input  data. 

(i.  The  simulation  output  should  interface  with  the  generic  display  driver  devel¬ 
oped  by  DeFtouchey  (9). 

It  is  believed  that  these  objectives  have  been  met.  C  structures  were  used  to 
create  objects  and  their  attributes.  This  design  enhances  both  the  modularity  and 
object-oriented  nature  of  the  simulation  code.  Structures  of  this  nature  ensure  that 
all  the  information  regarding  the  object  are  always  physically  lied  to  that  object  and 
can  be  found,  used,  or  modified,  by  making  the  correct  reference  to  the  instantiated 
structure.  The  usage  of  these  types  of  structures  also  gives  the  simulation  code  much 
of  its  flexibility  and  growth  potential.  Adding  to,  or  changing  the  existing  attributes 
of  any  of  the  structures  within  the  simulation  can  make  available  more  or  different 


information  which  in  turn  could  be  used  to  increase  the  complexity  and/or  realism  of 
the  simulation.  Adding  to  the  ability  of  the  code  to  be  easily  modified  is  the  overall 
structure  of  the  files,  their  interconnections,  and  the  generic  structure  of  much  of 
the  code.  For  instance,  the  simulation  structures  are  in  a  separate  file,  easily  found, 
and  easily  modified.  The  same  is  true  for  the  simulation  functions.  The  simulation 
driver  is  also  a  separate  package,  as  is  the  linked  list  code.  Either  package  could 
be  replaced  if  it  were  desired.  These  packages  were  also  created  using  a  fairly  strict 
modular  object-oriented  design,  thus  enhancing  their  modification  potential.  So,  not 
only  does  the  simulation  lend  itself  to  modification,  but  so  does  its  associated  code, 
in  part  or  as  a  whole.  Having  stated  the  above,  it  is  easy  to  see  that  objectives  one 
and  three  have  definitely  been  met.  Computational  complexity  is  reached  in  this 
simulation  in  two  ways.  First,  there  is  the  nature  of  the  calculations  themselves. 
This  simulation  makes  use  of  numerous  computations  involving  long  float  valued 
numbers.  Operations  on  these  numbers  include  addition,  ubtraction,  division,  sine, 
cosine,  tangent,  arctangent,  and  square  root.  The  second  area  of  computational  load 
comes  from  the  sheer  number  of  times  these  operations  are  required.  The  bottom 
line  is  that  computational  load  can  be  increased  simply  by  adding  objects  to  the 
simulation  scenario.  Thus,  objective  four  can  be  put  to  rest.  There  isn’t  much  to 
say  about  objective  five.  The  implementation  allows  the  flexibility  to  create  a  nearly 
unlimited  number  of  scenarios  and  thus  unlimited  simulations. 

5.2  Conclusions 

It  was  never  an  objective  of  this  work  to  create  an  accurate  military  simulation. 
Once  the  design  phase  began  in  earnest,  it  became  readily  apparent  that  had  accu¬ 
racy  been  a  requirement,  the  amount  of  work  required  would  far  exceed  what  could 
be  acc  omplished  by  one  person  in  one  thesis  cycle.  Realistic  military  simulations  can 
take  teams  of  programmers  and  modelers  years  to  produce  (13b  indeed,  the  creat  ion 
of  a  “representative”  military  simulation  proved  to  be  no  easy  task.  The  complexity 
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of  the  simulation  grew  quickly  as  the  possible  execution  paths  increased  with  every 
implementation  of  a  new  function.  In  fact,  trying  to  predict  all  the  events  of  sim¬ 
ulations  involving  more  then  five  interacting  objects  prior  to  the  actual  execution 
becomes  extremely  difficult,  if  not  impossible.  Once  the  execution  is  complete,  ver¬ 
ification  of  what  actually  occurred  is  somewhat  easier.  However,  stepping  through 
the  output  can  be  a  lengthy  process.  By  far  the  best  way  to  verify  the  output  is 
to  view  the  output  via  the  graphical  display  driver  discussed  earlier.  It  should  be 
pointed  out,  however,  that  viewing  the  output  does  not  necessarily  mean  that  all 
events  were  scheduled  properly.  Since  the  display  driver  operates  on  a  principle  of 
extrapolation,  an  object’s  position  will  continue  to  be  updated  even  if  an  event  is 
somehow  omitted.  The  best  approach  to  running  a  verifiable  simulation  is  to  first 
script  the  simulation  as  completely  as  possible;  second,  try  and  verify  a  printout  of 
the  output  file  against  the  script;  then  view  the  simulation’s  graphical  display  to 
check  the  overall  correctness  of  directions  of  movement,  relative  speeds,  kills,  and 
pit  ch  angles. 

It  is  felt  that  the  work  of  this  thesis  effort  represents  only  the  skeleton  of  what 
a  real  military  simulation  could  ultimately  look  like.  Addressing  the  basic  areas  at. 
least  in  some  way,  even  if  only  as  a  hook,  represents  a  significant  part  of  the  overall 
effort.  It  is  the  opinion  of  the  author  that  this  is  probably  the  most  difficult  part  of 
the  total  effort.  What  lies  ahead,  prior  to  parallelizing,  is  enhancing  the  code,  and 
a  i cling  realism.  This  part  is  the  “putting  the  meat  on  the  bones”  part. 

5.3  Recommendations 

Recommendations  generally  fall  into  two  catagories,  either  those  concerned 
with  enhancing  the  serial  version  of  the  simulation  code,  or  those  concerned  with  the 
parallelization  issues.  As  far  as  enhancing  the  serial  simulation  code,  the  possibilities 
are  almost  endless,  depending  on  the  level  of  detail  sought.  Listed  here  are  just  a 
few  of  those  possibilities: 
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•  Modify  the  sensor  check  algorithm  to  include  the  third  dimension.  This  would 
give  objects  a  spherical  sensor  zone  instead  of  cylindrical.  By  off-setting  the 
actual  object  location  from  the  center  of  the  sensor  zone,  one  can  create  a 
sensor  zone  in  front  of,  behind,  above  or,  below  an  object. 

•  Use  more  of  the  existing  object  attributes,  such  as  weapons  and  operator  at¬ 
tributes,  to  add  more  realism. 

•  Add  more  nondeterminism  into  the  detection  and  attack  processes. 

•  Add  more  error  checking  into  the  input  function.  Although  each  input  value 
cannot  be  verified  correct,  they  can  be  checked  to  be  within  acceptable  ranges. 

•  Terrain  still  needs  to  be  addressed.  This  also  creates  a  need  for  a  viable  im¬ 
plementation  of  a  Line  of  Sight  function. 

•  Modify  the  damage  assessment  function  to  include  damage  less  then  total  de¬ 
struction. 

•  Add  some  expert  type  decision  making  in  choosing  of  sensor  and/or  armaments 
for  an  object  to  use. 

•  Add  some  iiondeterminism  to  the  hil  miss  function. 

Parallelization  is  a  separate  issue.  The  issues  here  are  what  machine  to  use, 
distributed  or  shared  memory,  and  how  to  partition  the  simulation.  Suggestions  to 
these  questions  follow: 

•  Using  the  shared  memory  machine  would  alleviate  problems  associated  with 
global  data  which  may  make  things  a  little  easier  to  handle. 

•  If  the  choice  is  made  to  use  a  distributed  memory  machine,  it  is  suggested 
to  break  the  problem  space  up  into  areas  of  set  dimensions.  Then  create  an 
artificial  event  type  called  “reached -node-boundary”  to  represent  the  point,  in 
time  that  an  object,  needs  to  be  handed  over  to  another  node. 
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Appendix  A.  SIMULATION  CODE 


A.l  Simulation  Structures 

The  following  is  a  copy  of  the  simulation  structures  file,  simjstru.h. 


struct  location.type 

{ 

double  i. coord; 
double  y. coord; 
double  z.coord; 

); 


struct  zyz.velocitiea 

{ 

double  x.valecity; 
double  y. velocity; 
double  z.velocity; 

}; 


struct  orientation.typa 

{ 

double  roll; 
double  pitch; 
double  yaw; 

}; 


struct  rotation.rates 

{ 

double  roll. rate; 
double  pitch.rate; 
double  yaw. rate; 

>i 


struct  operator.type 

{ 

int  experience; 
int  threat. knowledge; 

>  ; 

etruct  performance. characteristics 

{ 

int  ■in.turn.radiue; 
int  max. speed; 
int  awe. luel.cona. rate ; 
int  ■ax.cliab.rate ; 

}; 


struct  sensors 

{ 

int  typa; 
int  range; 
int  reeolution; 
), 

struct  amanenta 
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int  type; 
int  rang*; 
int  lethality; 
int  accuracy; 
int  speed; 
int  count; 

); 

struct  defens  ive.syetons 

{ 

int  type; 

int  rang*; 

int  effectiveness ; 

); 


struct  targets 

{ 

int  target. type; 

struct  location.typ*  target. location; 

); 


struct  **«nt_arga 

{ 

double  *e*nt.tiae; 
struct  object.attrrbute*  eobjectl; 
struct  object .attribute#  ‘object 3; 
); 


struct  object. attributes 

1 

int  object. type; 

int  object. id; 

int  object. loyalty; 

double  current. tiae ; 

int  fuel. status; 

int  condition; 

int  vulnerability; 

struct  location.typ*  location; 

struct  xyz. velocities  velocity; 

struct  orientation. type  orientation; 

struct  rotation.ratea  rotation; 

struct  operator. type  operator; 

atruct  perfonance.characteristic*  performance; 

etruct  llnked.litt  eroute.dat a; 

etruct  linked. liet  eaeneore; 

atruct  llnkad.liat  earnaaanta; 

struct  linked. lilt  edafenaiva.ayatws ; 

struct  licked.liat  etarget.liat ; 

}; 


A. 2  Rizsim  Code 

The  following  is  a  copy  of  the  actual  simulation  code,  rizsim. c. 


•include  "11. h" 
•include  "sim.driv.h" 
•include  "*in_func.h" 
•includt  "sim.*tru.h" 
•include  "events. h" 
•include  <stdio.h> 
•include  <*mlloc .  h> 


. . . 

/•  DATE:  08/02/90  */ 

/*  VERSIOB :  0.0  */ 

/•  TITLE:  The  Mis  simulation  cod*.  Th*  •sore*  of  th*  simulation  run  */ 

/*  FILEIAME:  rixuim.c  */ 

/*  COORDIBATOR;  Rob  Him  ♦  / 

/•  PROJECT:  HS  Thus is  GCS-90D  •/ 

/«  OPERiTIBC  SYSTEM:  MS-DOS  */ 

/•  LAIGURGE:  Microsoft  Quick-C  */ 

/*  FILE  PROCESSIIG :  Link  ud  Compile  »ith  *im.driv.c,  *im.func.c,  events. c,  */ 

/•  and  11. c  */ 

/♦  COITEITS:  mo  prototype*  is  sost  section  •/ 

/♦  KUlCriOI :  Beeicelly,  this  cod*  intiiat**  the  execution  of  the  simulation*/ 

. . * . . . ♦  / 

. . . . * . . 

/«  PROTOTYPES  OF  FUICTIOIS  HITBII  RIZSIH.C  ♦  / 

/*..*...*********.****.***e*.*..***.****e***ee«e.**********ee»*»*»****»*..**./ 


void  start, display  O; 

void  etop.displaj  ()j  /•  double  Inst. event .time  •/ 
void  echedule.init .events  (); 
void  idvnt if y. icons  <)j 

int  compare. time  <);  /•  double*  timet,  double*  times  •/ 


. . . . 

/*  OLOBALS  USED  II  RIZSIH.C  •/ 

. . * . .*.«..**♦ . . . ♦•♦*♦*♦*/ 

struct  linked.liet  *mest«r_ob j.liet i 
struct  driver  *simulat ion. driver ; 
int  highest. obj. id  ■  0; 

. . ...*....*...** . *.*...« . . . . 

/«  RIZSIH.C  HUB  CODE  BEOIIS  HERE  •/ 

. . vs,.***..,** . **•*••«*• . . 

void  main  O 

( 

struct  linked. list  *stats. qutu*  *  BULL; 
struct  driver. data  *l*st. event  ■  BULL; 
double  last. event. time; 


struct  driver.dat*  *d*let*d„evsnt ; 
struct  linked.list  •deleted.event.list; 

identify. icon*  ()  ; 

s imulation.driver  a  make. driver  (8,  compare. tin*) ; 
mast *r. obj. list  a  ll.make  (FIFO); 
read.datafil*  ("datafile.c") ; 
schedule. init. events  (); 
at  art .display  () ; 

stats. queue  ■  execute, sim  (simulation.driver) ; 


last.*v*nt  *  (struct  driv*r„d*tto)ll.pop  (stats.quaua) ; 
last. **»nt. tin*  ■  »(doubl*s)l**t.*v*nt>>tia*; 

stop. display  (lsst.svsnt.tUi*); 

) 


^.,..*»OS*S*0*»***„*0**0*0***»0************0*«**000««***«*.**«*******«**«o./ 

/»  DATE:  09/30/90  ♦/ 

/♦  VERSIOI:  0.0  */ 

/*  TITLE:  stATt.displsy  */ 

/♦  NODULE. HUMBER:  0.0  •/ 

/«  DESCRIPTION  Uritss  s  start  display  atatag*  to  th*  diapaly  /11s  */ 

/♦  ALGORITHM:  optn  th*  dlplay  fils  •/ 

/•  srlts  thj*  start  display  attiaft  */ 

/♦  clot*  th*  display  < 11a  */ 

/*  PASSED  VARIABLES :  non*  */ 

/♦  RETURIS :  non*  */ 

/♦  GLOBAL  VARIABLES  PASSED:  non*  */ 

/•  GLOBAL  VARIABLES  ORAROED:  non*  */ 

/♦  FILES  READ:  non*  ♦  / 

/*  FILES  RR1TTER:  non*  */ 

/*  HARDWARE  IIPUT:  non*  »/ 

/*  HARDWARE  OUTPUT:  non*  »/ 

/♦  NODULES  CALLED:  non*  »/ 

/•  CALL1IC  MODULES:  nalnO  »/ 

/*  ORDER  OF:  This  function  is  of  ordtr  0(1)  •/ 

/«  AUTHOR:  Rob  Rizz*  */ 

/.  HISTORY:  non*  •/ 

. . . . . . . . . 

void  start. display  () 

( 

KILE  *ptr.to.di«pIay.fil*; 


if  ( (ptr.to.display.f 11*  •  fop*n  ("display . c"  ,  "a"))  !•  IULL) 

( 

fprintf  (ptr.to.display.f lit,  "50\n"); 
fclosa  (ptr.to.display.f ilo) : 

) 

«ls« 

printf  ("CARROT  OPER  DISPLAY  FILE  IR  START.DISPLAYXn") ; 

) 


. . * . . . «**/ 

h  DATE:  09/30/90  */ 
/«  VERSIOI :  0.0  •/ 
/«  TITLE:  stop.dlaplay  */ 
/*  NODULE. DUMBER :  i  .0  •/ 
/»  DESCRIPTIOR:  Writ**  a  stop  display  nassag*  to  th*  dispaly  fil*  •/ 
/»  ALGORITHM:  op*n  tho  dlplay  fil*  •/ 
/«  arlt*  thj*  atop  display  n«ssag*  •/ 
/•  clos*  th*  display  fil*  */ 
/»  PASSED  VARIABLES :  non*  •/ 
/*  RETURRS:  non*  ♦/ 
/*  GLOBAL  VARIABLES  PASSED:  non*  •/ 
/•  GLOBAL  VARIiBLES  CHARGED:  non*  */ 
/•  FILES  READ:  non*  ♦/ 
/«  FILES  WRITTER :  non*  •/ 
/«  HARDWARE  IIPUT:  non*  •/ 
/•  HARDWARE  OUTPUT :  non*  */ 
/•  NODULES  CALLED:  non*  »/ 
/*  CALLIRG  MODULES:  nainO  ♦/ 
/♦  ORDER  OF:  This  function  ia  of  ordtr  0(1)  */ 
/•  AUTHOR:  Rob  Rizz*  •/ 
/•  HISTORY:  non*  •/ 


A-4 


/ 


/******  Oeo-roeOe********.***************....*..*.*****',******* 

void  stop.dltplo;  Oast.evsnt.tiae) 
double  last.eoent  .tun ; 

{ 

FILE*  ptr.to.diepley.f il* ; 

if  ((ptr.to.display.file  -  fopen  ("display .c",  "a"))  !•  IULL) 
fprintf  (ptr.to.display.file ,  "M  llf\»" ,  laet.event.tiae)  ; 

} 


. . . . . 

/•  DATE:  09/30/90  •/ 
/*  VERSIOR :  0.0  •/ 
/•  TITLE:  conpare.t iae  */ 
/»  MODULE. IUHBER :  2.0  •/ 
/»  DESCRIPTIOI :  Used  by  th*  sia.drioer  to  dotorain*  sorting  of  eoents  */ 
/•  ALGORITHM:  subtract  tiaol  from  tia*2  */ 
/*  PASSED  VARIABLES:  int  tiaol,  int  tiaa2  */ 
/«  RETURHS:  1 ,  or  -1  «/ 
/•  GLOBAL  VARIABLES  PASSED:  none  */ 
/«  GLOBAL  VARIABLES  CHARGED:  none  •/ 
/•  FILES  READ:  nono  */ 
/*  FILES  HRITTEI:  nono  */ 
/♦  HARDWARE  IMPUT:  nono  */ 
/*  HARDWARE  OUTPUT:  nono  •/ 
/•  MODULES  CALLED:  nono  •/ 
/•  CALL1IG  MODULES:  aainO  */ 
/»  ORDER  OF:  This  function  is  of  ordor  0(1)  «/ 
/*  AUTHOR :  Rob  Rizza  */ 
/*  HISTORY:  nono  •/ 
/••*•• . . . . . . . . . . . 


int  compare. tine  (tiaol,  tiao2) 
doublo  otiaol ; 
doublo  *tiao2; 

{ 

if  ((•tin*2  -  otiaol)  <  0.0) 

return  -1 ; 

else 

return  1 ; 


. . . a**************** . 0*0.00000 . 00.0* . . 

/*  DATE.  09/30/90  «/ 
/•  VERSIOR :  0,0  */ 
/•  TITLE:  schodulo.init.oooats  */ 
/<•  MODULE. IUMBER :  3.0  */ 
/•  DESCRIPTION  Sehudules  tho  firat  ovont  for  all  (.Ejects  */ 
/•  ALGORITHM:  Pop  th#  pointer  to  tho  first  object  froa  the  aastor  obj  list  */ 
/*  schsduls  tbs  object's  event  •/ 
/•  rtplace  tho  pointer  into  th*  natter  obj  list  */ 
/.  PASSED  VARIABLES :  none  •/ 
/•  RETURRS:  none  •/ 
/*  GL0B1L  VARIABLES  PASSED:  none  •/ 
/*  GLOBAL  VARIABLES  CHARGED:  ncuo  */ 
/*  FILES  READ:  none  */ 
/*  FILES  WRITTE1:  none  */ 
/•  HARDWARE  IRPUT:  none  */ 
/•  HARDWARE  OUTPUT,  none  •/ 
/*  MODULES  CALLED:  non*  •/' 
/♦  CALLIRG  MODULES:  asinO  »/ 
/*  ORDER  Of:  This  function  is  of  order  0(n)  shore  n  is  the  nuabor  of  •/ 
/ *  in  the  Banter  object  list  */ 
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/•  AUTHOR :  Rob  Rizza  */ 

/*  HISTORY:  noao  »/ 


void  schadula.init.aaanta  () 

{ 

int  objects,  i; 

doubl.  Initial.tlaa; 

doublo  *ptr_te„initisl_tlaa  •  HULL; 

•tract  objsct.sttributas  apt  r.to. object  ■  HULL; 

■tract  aasnt.args  *ptr.te_a»ant_args  ■  HULL; 

objects  »  ll.lngth  (maatar.obj.liat) ; 

for  Ci  ■  1;  i  <■  objocta;  t++) 

{ 

pt r.to.object  ■  (struct  object_attributai.)ll_pop  (uatn.obJ.Uit); 

if  (ptr.to.object-iobject.type  <■  S) 

{ 

if  ((ptr.tc.eaent.args  ■  (struct  aaant_args*)Bailac 

(sizoof (struct  eaant.argi)  ) )  ■■  HULL) 

print*  ("CAHIOT  MALLOC  II  SCHEDULB_lirT_£VEITS\n") ; 

ptr.to.evant.arga-iobjactl  «  ptr.to.object ; 
ptr.to_e»ent.arga->obj«ct2  “  IULL; 

ptr.to_avant_arga-isront.tiB*  «  ptr.to.objact-icurrant.tina; 

if  ((ptr.to.initial.tiaa  •  (double.)iaalloc (aizaof (init ial.t in.) ) ) 

««  IULL) 

print*  ("CAIIOT  MALLOC  II  SCHEEULE_ISIT_EVEITS\n") ; 

•ptr.to.initial.tina  •  ptr_to_cbject->current_tin. ; 

schadula.sTant  (aiBulation.driver,  ptr.to.initial.tiaa, 
raachad.turnpoint ,  ptr.to.aaant.args)  ; 

> 

ll.inaart  (aaatar.ob j.liat ,  ptr.to.ob joct) ; 

) 

> 


. . . . . . . . . 

/*  DATE:  C9/30/&0  •/ 

/♦  VEftSIOI:  0  0  */ 

/*  TITLE:  id-ntify  icons  */ 

/*  MODULE. IURBER :  4.0  •/ 

/•  DESCRIPTIOI:  Son-’-’  ..  display  f cha  lagal  icons  for  this  sisalation  »/ 

/•  ALGORITHM:  Opan  play  filo  */ 

/•  Sand  tba  propriata  icon  idantif  >-,ra  »/ 

,  ■<  Cloaa  the  display  fila  •/ 

/*  PASSED  VARIABLES:  nona  •/ 

/•  RETURIS  :  nona  */ 

/•  GLOBAL  VARIABLES  PASSED:  nona  »/ 

/*  GLOBAL  VARIABLES  CHIRGED:  nona  */ 

/*  FILFS  READ:  nona  •/ 

/*  FIL  VRITTEI :  nona  •/ 

/-  HARDWARE  1IPU7:  non*  «/ 

/*  HARDWARE  OUTPUT:  nona  •/ 

/•  M0DUI.es  CALLED:  nona  */ 

/*  CALLIRG  MODULES:  BiinO  «/ 

/•  ORDER  OF:  This  function  ia  of  order  0(1)  */ 

/*  AUTHOR:  Rob  Rizza  «/ 

/•  HI  ITOrtY :  nona  */ 

. . .  „,.*.e..e.eeeee.aee..ee.e.*eeeeeee.«e. . a . . . . 

void  idt”".  () 
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{ 

FILE  *ptr_to_di*pl*j_f il*; 

if  ((ptr.to.diaplaj.fil*  ■  fop*n  ("displaj.c"  "a"))  !■  ULL) 

{ 

fprintf  <ptr.to.diaplaj.fi!*,  "32  1  fl8\n  ")i 
fprintf  (ptr.to.diaplaj.fil*,  ”32  2  ■iglX.V) ; 
fpriutf  (ptr.to.diaplaj.fil*,  "32  3  ■isaUtXn") ; 
fprintf  (ptr.to.diaplaj.fil*,  "32  4  tankXn"); 
fprintf  (ptr.to.diaplaj.fil*,  ‘*32  S  truckXn"); 

fcloa*  (ptr.to.diaplaj.fil*); 

> 

•la* 

printf  ("CAIIOT  OPEI  DISPLiY  FILE  II  IDEniFY.ICOIXn") ; 

> 


A. 3  Events  Code 


The  following  are  copies  of  the  simulation  events  code,  events. h  and  events. c. 


/•a**************************  *T*nts .h  •«•«***••*♦***••******»**•♦***•*•••/ 

void  r«ach*d_turnpoint  ();  /•  atract  *v*nt_*rgs*  «*«nt .argument  */ 

void  *nt*r*d_s«naor.rang*  0:  /•  atruct  *vant,.arg**  *v*nt.ferguiient  •/ 

void  aittd«.s«naor. contact  ();  /*  atruc.t  *v*nt_arga*  *T*nt_arguai«nt  */ 

void  collision_di*tanc*.r«ach«d  ();  /•  struct  *v*nt_arga*  *v*nt .argument  •/ 

void  ordnanc«_r*l*a**d  ();  /•  struct  *v*at_arga  **v*nt_argu*nt  */ 

void  ordnanc*.r«ach*d.targ«t  ();  /*  struct  *v*nt.arga  **v*nt.arguaent  •  / 


. . . . . . . . . . 

/»*«*«*»***********•»*•***»*•••*•*  *v«nt*  c 
/•♦• . . . . . . . . 

/•  DATE :  08/02/90  •/ 

/•  VEBSIOJ:  0.0  */ 

/»  TITLE:  Th*  cod*  for  tb*  *v*nt*  of  thi*  *iaulation  •  / 

/•  FILEIIHE:  *v*nta.c  •/ 

/»  CDDRDII1TDR:  Rob  Rizza  */ 

/•  PROJECT:  US  Thesis  0CS-90D  •/ 

/•  OPERATING  SYSTEK  HS-DOS  •  / 

/•  LANGUAGE :  Micro  ft  Quick-C  •  / 

/*  FILE  PROCESSIIG:  Link  sad  Conpile  with  *x*cutabl*  fil*  which  .»••*  this  •  / 
/♦  coda.  •/ 

/•  COITEITS :  saw  tha  *v*nt*.h  cod*  for  prototjp**  of  function*  in  avanta.c  •/ 
/*  FWICTTOI :  Provide*  tb*  aiaulation  with  lagal  *v*nta  for  tb*  *iaul*tion  •  / 

. . . . . . . . . . . . . 

dinclud*  <nalloc.h> 

•includ*  <*tdio.h> 

•includ*  "*v*nt*.h" 
tinclud*  "aia.stru.h" 
tinclud*  "sia.func.h" 


void  r*acb*d.turnpoint  (*v*nt.argaaent) 
struct  *v«nt.*rga  *-»v*nt_argujaent; 
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{ 

printf  ("Objact  Xd  has  REiCBED.TUlBPT  at  Xlf\n", 
evant_argu*Bnt->objactl->objact_id,  avant. argument -> event .time) ; 
updata.poaition  (evant.argumant) ; 
aenaor.chack  (avant.argaaant) ; 

> 


void  anterad.aanaor.range  (evant.argumant) 
struct  avant.arga  eevent.argument; 

{ 

printf  ("Object  Xd  baa  EITEREB.SEISOk.HIQE  at  tlf\n", 
event. argument->objactl->object. id,  event  _sxgna«nt- invent  _t  ime) ; 
updata.poaition  (event. argnaent)  ; 
aanaor.cback  (event .argument) ; 

> 

void  made.sensor.contact  (event. argument) 
struct  avant.arga  as vent .argument; 

{ 

printf  ("Objact  td  has  HADE.SEBSOR.COITACT  at  Uf\n", 
event.argument->objectl->object.id,  avent.argument-ievent.t ue« ) ; 
updata.poaition  (event. argument) ; 
operator.evaluation  (avant .argument) ; 
sensor. chock  (evant.argumant) ; 

> 

void  crdnsnca.ralaaaad  (evant.argumant) 
struct  avant.arga  aavant .argument ; 

( 

printf  (“Objact  Xd  baa  bean  RELlaSED  aa  ORDIAICE  at  Xlf\n" , 
event. argument-iobjecti-iobject.id,  event.arguaent-ievent.t  ime) ; 
update. position  (event. argument) ; 
sensor. check  (event.argument) ; 

> 

void  ordnance.reached.target  (event.argument) 
struct  avant.arga  eevont. argument ; 

{ 

double  in.i.seconda j 

struct  avant.arga  anaa. avant. arguaunt ; 

printf  ("Objact  Xd  has  reached  it’a  target  ORD«AJ!CE_REACBED_TAR<iET  at  XlfVn", 
event. argu»ent->objactl->objact. id,  event_irgument->event_t  iaa) ; 
updata.poaition  (avant. argument) ; 

in.x.aoconds  ■  event. argument ->avent .time  -  event_argument->object2->curre»t_tinc : 
add.nev.routapoint  (event. aTguaent->objact2 ,  in. x. seconds) ; 

if  ( (nev. event .argument  a  (atroct  event _arga*)*alloc (site of (struct  avant.arga))) 
—  BULL) 

printf  ("CAIIOT  HALLOC  ■EW.EVEIT.AtOUHEBT  II  ORDIAICE. AEACB  ED. TARGET', n") ; 

mb. avant  _ergument->objactl  ■  event. *rgument->objact2; 
new. event _argumant->objact2  ■  avant. argnmant->ob jactl ; 
new. event _argumer,t->event. time  ■  event .ar gum.  ->e vent. time  , 

printf  ("Objact  Xd  baa  ORDIAICE. IE ACHED. TARGET  at  XlfVn", 
event. ergument->objactl->objact. id ,  avant. argument->avent. time)  : 
updata.poaition  (nav.evant. argument) ; 
hit.uiss  (avant. argument) ; 
hit. bibb  (nes.event.argument) ; 

) 

void  collisicA.distanca.raacbad  (event. argusont) 
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struct  •▼•nt.trgs  *«T«nt.argu»*nt; 

{ 

update.poaition  <  event  .argnent) ; 

damage. assessment  (avent_argn»ent->objectl) ; 

sensor. chaek  (evant.argument) ; 

> 

A. 4  Functions  Code 

The  following  is  acopy  of  the  simulation  functions  code,  sim _func.h  and  sim.func.c. 

/*••••*••*»*•»*•«»•*•»«••»•»•••»*  •iM.foBC.h  *«••••••*«••*•**********•*••***•*•••♦/ 

void  add.event. coords. to.route  ();  /•  struct  avant.args  eevent.argument  «/ 

void*  add.nes.routvpoint  ();  /•  struct  object. attributes  eobject.inf o,  doubls  in.r.seconds  •/ 

void  attack  0;  /*  struct  event.args  eavant. argument  •/ 

void  calc.curr.orientat ion  ();  /a  struct  object.attributes  *object_info  •  / 

void  calc.curr.velocitias  ();  /•  struct  objact.sttributss  eobject.info  a/ 

doubla  calc. time.  at. next .root apt  ();  .'a  struct  objact.sttributss  *objact.info  •  / 

doubla  calc.time.at.nextnext.routept  <);  /a  struct  objact.sttributss  vobject.info  */ 

void  damage. asaeaasent  <>;  /•  struct  avant.args  eavant. argument  */ 

doubla  difference. in.altitude  ();  /•  struct  avant.args  savant. argument  a/ 

void  avada  ();  /a  struct  objact.attributaa  eavadar ,  struct  objact. attributes  *evadad  */ 

int  get  .sensor  .rango  ();  /*  struct  objact.attributaa  eobject.info  a/ 

void  kit.aii.SB  ()  ;  /•  struct  avant.args  aavvnt. argument  a/ 

int  line. of. sight  (>;  /a  struct  avant.argi  •avant.argunent  */ 

int  on.collision.course  <)i  /*  struct  avant.args  aavant.arguaant  a/ 

int  on.tsrgat.list  ();  /‘struct  objact.sttributss  eobjactl,  struct  objact. attributes  aobject2*/ 
void  oparator.evalnation  O;  /a  struct  avant.args  savant .argnaant  a/ 
void  raad.dataf  ils  () ;  /*  char  *path  a/ 

void  aand.fupdate  O;  /*  struct  objact. attributes  eobjact.info  a/ 
void  sensor. check  (>;  /a  struct  avaut.nrga  *a»ant .argument  */ 

struct  linkad.list*  -arminsta. objects  ();  /a  struct  avant.args  esvant. argument  ♦  / 
void  update. object. current.time  (>  ;  /a  struct  avant.args  *event. argument  */ 
void  update. poait ion  <)  ;  /eetruct  avant.args  *avant .argument  * / 

/...«,*eeeee**eeee**eeeeeee*eeeeeeeeee*ee.e*.eeeee*eeeeeeee*e*eeeeee.e*eeee«..*. ..**•/ 
/••«r»*ee*e**eeeeee*«eeeeee*eeeeeevee  aim.func  .c  eeeeeeameeveeeeeeeeeeeeeeveeeeeeeeea/ 
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/••••••••••••••••••**o********o*****»*******************«*e*e*o************«*/ 

/*  DATE:  0S/02/90  */ 

/•  VERSIOI :  0.0  •  / 

/♦  TITLE:  Event  Supporting  Functions  for  of  it.battle.sim  •/ 

/«  FILEUHE:  •  im.func.c  •/ 

/*  COORDIIATOR:  Rob  list*  */ 

/•  PROJECT;  RS  Th«sis  0CS-90D  */ 

/•  OPERATIIG  SYSTEM:  MS-DOS  */ 

/♦  LAROUAQE :  Microsoft  Qulck-C  */ 

/*  FILE  PROCESSUS:  Link  tad  Compile  sith  executable  file  thick  uu  this  */ 

/•  codo.  */ 

/•  COITEITS:  ooa  th*  •ia.fiac.h  codo  foi  oi  t>iar‘  l*«i*  •/ 

/•  FUBCTIOI:  Provide*  tho  simulation  aith  the  fax.  ioo*  roudad  to  run  tho  */ 

/•  simulation  */ 

Z************************************************************.,***************/ 

tincludo  <string.h> 
v include  <stdio.h> 

/  *  <‘.nclud*  {process. h>  *****  consent  out  to  run  on  tho  aim  •••••*•»/ 


tinclud*  <itath.h> 
tinclud*  <nalloc.h> 
tinclud*  "ain.stru.i." 
tincludo  "11, h" 
tinclud*  "ovonta.h" 
tincludo  "*im_func .h" 
tinclud*  "sim.driv .h“ 

tdefir*  PI  3. 10159 
tdefino  TRUE  1 
tdefine  FALSE  0 
tdofin*  HISSLE  3 


. . . . . . . *.*•*«•«•/ 

/•  DATE:  09/30/90  «/ 

/*  VERSIOI:  0.0  */ 

/•  TITLE:  add.evant.coorda.to.rout*  */ 

/•  HODULE.BUHBEk :  2.0  •/ 

/*  Dt'.SCKIPTIOl :  Adda  n*v  routapoint*  to  th*  otjscta  in  event. argument  •/ 

/•  bas*d  on  th*  tin*  to  th*  ***nt  */ 

/«  ALGORITHM:  Calculat*  the  *v*nt  tine  */ 

/•  call  add.nas.routepoint  */ 

/•  PASSED  VARIABLES:  event. ergs  **v*nt_argnn*nt  */ 

/•  RETURIS :  non*  •/ 

/•  GLOBAL  VARIABLES  PASSED:  none  •/ 

/*  GLOBAL  VARIABLES  CHAIGED :  non*  •/ 

/«  FILES  READ:  non*  »/ 

/•  FILES  tfhITTEI:  non*  •/ 

/•  HARDWARE  IRPUT:  non*  */ 

/*  RARDVARE  OUTPUT :  non*  »/ 

/«  MODULES  CALLED:  non*  •/ 

/*  CALLIIG  NODULES:  a«naor.ch*ck  */ 

/*  ORDER  OF.  This  function  is  of  ord*r  0(1)  */ 

/•  AUTHOR:  Rob  Pizza  »/ 

/*  HISTORY:  non*  •/ 

. . . . . 

void  *dd_*»*nt.coord*.to_rout*  (•vant.argunant) 
struct  event. arg*  **vent. argument; 

{ 

doublo  tim*_to_«v«nt ; 


if  («v*nt.*rgum*at->obj*ctl  !*  HULL) 

{ 

tin*. to. event  ■  •v«nt.arguB*nt->*v*nt.tiao  -  event. »rgun*nt->ooj*ctl->current„time  . 
add.ntv. routapoint  (event. argument ->obj*ctl ,  tine.to.avent)  ; 
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} 

if  (avant.argUBant-Sobjact?  !■  BULL) 

{ 

tiiaa.to.evont  “  avant.argTuaent->avant.ti»e  -  avont.argunant ->objact2->currant _t  uae ; 
add.nas.rontepoir.t  (avant_azguaant->objact2 ,  tiaa.to.avant) ; 

> 

j 


/»«*aaaaaaa.eaaaaeaaoaaaaaaaeaaaa.oaaaae.eeaaa.eoaeaaaao.a,o.eaaaaaaaaaa.aaaa/ 

/•  MTb;  06/13/90  */ 

/*  VERSIOI :  0.0  ♦/ 

/•  TITLE:  artd.nai.routopcint  •/ 

/a  NODULE.IUHBER:  2.1  */ 

/•  DESCRIPTION  This  function  !■  mad  to  dataraina  tha  location  of  tha  nas  a/ 

/a  turnpo int  addad  la  xeaponse  to  an  a*ada  raqnaat  */ 

/a  ALGORITHM:  -  using  tha  currant  x,  j ,  and  s  velocitias,  add  in.x.aaconda  v/ 

/*  timas  aach  of  thoir  raspactiaa  aalsaa  to  tka  currant  a/ 

/a  x .  y ,  and  t  coordinates  •  / 

/a  PISSED  V4RIIBI.es  :  objact.attributaa  aobjact.info,  double  in.x.aoconda  a/ 

/a  RETURIS :  nona  */ 

/a  GLOBAL  V4RI4BLES  PASSED:  nona  a/ 

/a  GLOBAL  VARIABLES  CHARGED :  none  a/ 

/a  FILES  READ:  none  •  / 

/a  FILES  WRITTEI :  »/ 

/a  HARDWARE  IVPITT:  nona  a/ 

/a  HARDWARE  OUTPUT:  nona  a/ 

/a  NODULES  CALLED:  none  •  / 

/•  CALLIIG  NODULES:  evade,  sensor. chock  */ 

/a  ORDER  OF:  This  function  is  of  order  0(1)  •/ 

/♦  AUTHOR:  Ret  Rizsa  */ 

/a  HISTORY:  none  •  / 

. . aaaaaaaaaaaaa . aaaaaa.aa . a . a,,,.*,*,,,,,,/ 

void  eadd.res.routopoiut  (object. info,  in. x_ seconds) 
struct  object. attributes  aobjact.info; 
double  tn.r.seconda ; 

{ 

struct  location. type  anaa.naxt.pt  •  HULL; 


if  ((nos.naxt.pt  *  (struct  locct icii.typaa)nallec(airaof (str-  ct  location.,  type)  ))*»HULL> 
return  HULL; 

now.next_pt->i. coord  •  (objoct.info->locstion .x.coord  *  (in.x. seconds  a 
ob ject_info->velocity .(.velocity) ) ; 

ncs.next.pt-by.eoord  *  (object_info->locat ion .y.ceord  ♦  ( in.x. second*  • 
eb j tct. inf o->»elocity.y. velocity)) ; 

new.novv.pt->*. coord  »  (objoct.ini o->l«cat ion. x.coord  •>  (in.x.svcomlu  • 
cbj«ct.ii:f<>->velocit  y.z.valocity)) ; 

ll.inaort  ( object. inf o->route_deta ,  nea.next.pt); 

> 


/eeeeaaaaeeeeaaeeeeaeeaeeeeaeeeeeeeaeeaeee ...aoeaeeaavavaaaaaaa^c ..aaa.teaa.a, 

/o  DATE:  10/08/90  a/ 

/a  VERSIOI :  0.0  •/ 

/a  TITLE:  attack 
/a  NODULE.IUHBER :  2.2 

/a  DESCRIPTION  Creates  a  NTSSLE  object  and  firaa  it  at  »  intoneiad 
/a  target  */ 

/a  ALGORITHM:  Create  a  HiSSLE  object  a/ 

/a  Create  and  load  it’a  route  points  *  ‘ 

/a  Schedula  an  ordnance  relaoaad  evout  '  i 

/•  PASSED  VARIABLES:  avent.arga  aevant.argunant  •/ 


c 


/•  RETUKIS  :  BOB*  »/ 

/•  GLOBAL  VARIABLES  PASSED:  BOB*  •/ 

/•  GLOBAL  VARIABLES  CBAIOED:  bob*  •/ 

/*  FILES  READ:  b«b*  •/ 

/*  FILES  URITTEI:  non*  ♦/ 

/*  HARDWARE  IRPUT:  bob*  */ 

/*  BARDVAIVE  OUTPUT;  bob*  *' 

/»  NODULES  CALLED:  bob*  •/ 

/♦  CALLUS  NODULES:  •/ 

/•  ORDER  OF:  This  function  1*  of  ord»r  0(1)  *f 

/•  AUTHOR:  Rob  Rixxa  •/ 

/*  BISTORT:  BOB*  •/ 

. . . 

void  attack  (ovs&t.arguM&t) 

•tract  ovoBt.arg**  ovont.arguMBt ; 

{ 


•xt«rB  » tract  linkvd.llst  *ma*t*r_obj JLiat ; 

•xt«ro  (tract  driver  vsiMalation.drivvr ; 

•xt«m  int  highest. obj.id; 

struct  locatiofl.typa  vtvapl,  t  VBisslv.routsptl ,  vaisslo.rout *pt2 ,  v«iscle_routept3; 

struct  obj«ct_attribut**  vaiaalo; 
struct  *v*nt.args  vnaw.ovvBt  .argument ; 

FILE  *ptr.to_diaplay_f il«; 
dnubl*  *tiai*_ptr; 

if  ((Bisai*  ■  (struct  obj*ct.attributsto)Balloc(sizaof (struct  objact.attribums)))  !*  MULL) 

{ 

aisal«->obj<aCt.typo  *  3; 

aissla->obj*ct.id  ■  ♦♦highvst.obj.id; 

aiasl«->curr«nt.tiM  »  avoa*  xrg«oat->av<int_tiaa; 

misalo-Hocat  ion.  x.coord  •  *v*nt.arguB*at->obj*ctl->locatio.  x.coord; 

aisslo-ilocat ion. y. coord  *  o*ant.arguBont*>obj*etl->locatii,n.y. coord; 

nisslo-hlocat  ion.  x.coord  •  svant _nrgumont->objsct : ->loc»t ion . x.coord; 

uisslo->volocity.x_valocity  •  1000.0; 

niasla-ivalocity.y.valocity  ■  0.0; 

aisalo-ivolocity.x.volocity  »  0.0; 

Bi8sl«*>orl*ntation.ya«  ■  0.0; 
aiasl*->ori*ntation. pitch  ■  0.0; 

BissX**>ori*ntation.roXX  *  0.0; 
nissl*-->rot*tioB.7<\v_rat«  *  0.0; 

Bisal«->rotatioB.pitck_rat*  *  0.0; 

Bissl«->rotation.roll_rat*  ■  0.0; 
ui88l«->s*naora  »  BULL; 

Bissl*->targ*t.list  “  BULL; 

BissX*->anaB*Bts  ■  BULL; 
nissl«->S»f*n«ivc.*yata»s  a  HULL; 

t*npl  »  11. pop  (*v*Bt_argBB*nt">ribj«ct2->rout*.data); 

BiaaX*->rout*.data  '•  ll.mska  (LIFO); 

aiads.routoptS  ■  (struct  location.typ*»)Bolloc(aix*of (struct  location. typ*)) ; 
aisal«.rout'vpt3->x_coord  ■  ta*pl">x_eoord; 

■iscl«.rout*pt3~>y. coord  •  t*apl *>y. coord; 
aisslv.routopt3->x. coord  ■  t*Bpl->x. coord; 

uissl*.rout*pt2  ■  (struct  loci:tioB.typ**)BalXoc(aiB*of  (struct  locat  ion.typ*) )  ; 
nisslv.  rout *pt2->i. coord  ■  ovoBt.axgua*nt->objvct2->locstion. x.coord  ♦ 
((•v*nt.argur<«nt-iavant.tiBv  -  ovant„4rgu»*nt->objact2->eorrant_tij»«)  » 
•V€9t.arguBOBt->objact2->valocity  .x.voloeity) ; 

jxssl*. rout. *pt2->j. coord  ■  ovant. arguB*nt->obj«ct2->locv.l ion . y.coord  * 

( (ovant.arguBont~hovoat.tiao  -  ***at_»rgua*p.t->obj*ct2->cu.Tr*nt_tL**)  * 

ov«nt_*rguB*nt->obj*ct2*>*«locity  .y_valocit.j) ; 

aissla.rout*pt2->*. coord  "  ***nt.*rgu»ant'->objscr.'.2->lecation. x.coord  ♦ 


A- 12 


f  f  it  ■  nt.irpimnt-*-  iTimt.tlm  -  avaBt.argu«iaBt->obJaet3->cnrrant_ti«a)  * 
avonV.trgtmaBt-iobjaetJ-ivalocity  . x.valocity) ; 

if  (fibi  (ni#ala_routapt2->x_coord  -  ■ia»la.routapt3->i_coord)  <  C.vvl  a 
fabu  (»iaala_rout«pt2->y_eoord  aiaala.ro>itapt3->y.coord)  <  <>.001  Ik 
fabx  (■leala_routapt2->z_ceord  -  ■iaala.roatapt3->z.coord)  <  0.001) 

< 

tup]  ■  11. pop  (mat.U(i»igt“>»bj«eH*>tt»ti.ilit4); 
aiaala.ront  apt3->x_coord  ■  tanp2->x. coord; 
aissla.rontapt3->y, coord  »  tonp2->y. coord; 
aissla_routspt3->x_coord  *  to»p2->x_coord, 
ll.inaart  (nixalj-irnuta.data ,  Biaala.rootaptd) ; 
ll.inaart  (niiala-irouta.data,  Biasla.r'  Mapt2)  j 
ll.inaart  (avant.nrgunart->ob jact2->routa.d»ta,  ta*p2) ; 
ll.inaart  (a«Mt.irgaaa>t->objatt]  1 » outa.dat a,  tanpl); 

} 

«laa 

{ 

ll.inaart  (•Taat.argtmaii«->objact2->ronta.datal  tanpl); 
ll.inaart  (niaala-irouta.dat  a,  ■iaala_ror.tapt3) ; 
ll.inaart  (niaala-ironta.dat a ,  ■isala_routspt2) ; 

> 

aimla.rov.toptl  •  (struct  location.  typa*)aalloc(ai:caof  (struct  local  ion.  typo)  )  ; 
aiJS.e.n.ut  apt  l->x. coord  a  aiaala-ilocat ion. x.coord ; 

R'.aala.romoptl -iy.coord  •  miaxla-ilocation. y. coord ; 
aisale.roat .*ptl->x_co6rd  *  ni*ala->location. x.coord; 
ll.inaart  {r.ia*la->rout«_(lut»,  nitsla.rootaptl) ; 

if  <  (naa.aaant  .argunaat  ■  (struct  avant_argsa)nalloc(sixaof  (struct  avart.arga) ) )  *»  IUI.L) 
printf  ("CllIOT  IULL0C  ILV.EVKIT..1AGU1IEIT  II  ATTACI") ; 
naw.ovant..ir|jxiMant->ob  jactl  *  niaelo ; 
na»_a»ant_argv«ant“>obiact2  *  ar.ot.ar junant->objaCt2 ; 

[law.avent.arguaant -»aaant.. tins  ■  «var.t_irgnnaut~>sTsnt.t ina ; 

ptr.to.display.fila  “  fopan  ("display .c", 

fprintf  (pt.r_to.diaplay.f il« ,  "30  Xd  XiVn",  nlaela-ioV jact.id,  niaala-iob.jact.dype) ; 
fcloaa  (ptr_.to.displny.fila)  , 

ll.  inaart  Caaatar.ob j.list ,  niaala)  ; 

i.f  <(tia*.ptr  ■  (donblaa)anlloc(r.ixaof (doubla)))  ■*  IULL) 
printf  ("CAMOT  NALLOC  TIRE.PTA  II  ATTACK") ; 

•  tima.ptr  •  aaant .argtmant-iaaant.Vma ; 

schodnla.avont  (ainulation.di  irar ,  t  ijia.pt r,  ordnanca.ralaasad ,  nav.av*..t.argumer.t) ; 

i 

al.to 

printf  ("CAIIOT  IAL10C  RISSLB  II  HUCI"); 

) 


/saaaasttaaaaaojasaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaasstaitas . . 

/a  DATE:  08/23/90  */ 
/a  VERSIOV :  0.0  •/ 
/•  TITLE:  enlc.et.rr  .orient  at  ion  •/ 
/•  HUDOLE.IUHBEA;  2  3  */ 
/a  DiSCklPTIOk:  This  function  ia  uaad  to  datanaina  tba  Baa  oriaatation  of  a  a/ 
/*  objac.t  banau  on  its  currant  and  uaxt  poaition  •/ 
/*  AiODAITHH:  -  axing  tba  arctangent  friction  calculate  tha  engla  f rca  a/ 
/a  tbo  horizontal  •/ 
/a  PASSED  V41HSi.ES:  cbjact.iBfo  */ 
/♦  RETVHIS :  none  •/ 
/*  GLOBAL  VARIABLES  PISSED:  Bona  «/ 
/•  GLOBAL  VARIABLES  CdllGED :  Bona  */ 
/a  PILES  RF.AD:  none  */ 


A-  13 


J*  FILES  mtllEI:  »/ 

/*  HARDWARE  HPUT:  non*  «/ 

/•  HARDWARE  OUTPUT:  non*  */ 

/♦  MODULES  CALLED:  non*  •/ 

/•  CALLIIQ  MODULES;  *ni«  •/ 

/•  ORDER  OF:  Thi*  function  in  of  order  0(1)  •/ 

/•  AUTHOR:  Rob  Rixz*  •/ 

/•  HISTORY:  non*  •/ 

»oid  calc.coxr. orientation  (object. info) 
atrnct  object.attribute*  eobjtct.info; 

( 


doubl*  delta. z,  delta. 7,  delta.z,  distance,  angle,  pitch; 

•tract  locat ion.typ#  *n*xt .rout*. point  ■  HULL; 

if  (U.io«npty  (object. lnfo->rout*„d*t*)  !•  TRUE) 

( 

next. rout o.poiat  ■  (strnct  location.tYp«*)ll.pop  (objoct_info-Xouto.dat*) ; 
delta. x  ■  n«xt.vont*.point->x.coord  -  object. info-hloeation.x.coord; 
delta. y  ■  n*xt_routo_point*>y_coord  *  obj*ct_info~>location.y. coord; 
delta.z  ■  next. route. point->z_coord  *  object. iafo->loc*tion.z. coord; 

angle  ■  a  ten  2  (delta. y,  delva.i)  *  360  /  (2  »  PI); 

if  (angl*  <  0.0) 
angle  ■  360  *  angle; 

if  (angle  >■  C.O  AR  angle  <*  90.0) 

object. info-horiestation.yav  K  00.0  -  asglo; 

else  if  (angle  >  90.0  at  angle  <■  100.0) 

object.iafo-ioiientation.yaw  ■  360.0  *  (angle  *  90,0); 

else  if  (angle  >  130.0  AR  angle  <■  2/0.0) 

object.info->orientation .yaw  ■  270.0  -  (angle  -  180.0); 

els* 

object. info->ovientation.y*v  ■  180  -  (angle  -  270.0); 

pitch  «  i»tan2  (delta.z,  (distance  »  eqrt  < (delta. x*delta, *>e(delte_y*delte.y>) ) >  • 
300  /  (2  e  PI); 

object. into->orientation. pitch  «  pitch; 

object. info->orientation. roll  ■  object. info->ori*ntation,  roll; 

11. insert  f object. info-irouto.date,  next .route. point ) ; 

) 

else 

( 

object. info->orientation. pitch  ■  0.0; 
ob ject.info-horientation.roll  •  0.0; 

) 

> 


. . . . . . . 

/♦  DATE:  08/24/90  •/ 
/•  VFRSIDI :  0.0  •/ 
/•  TITLE:  calc.cnrr.eelocitioa  •/ 
/*  MODULE. SUNBEE :  2.4  ♦/ 
/»  DESCkIPTIdl :  Th<#  function  i*  uoed  to  detenine  the  nee  eelocity  vector*  •/ 
/*  of  a  vehicle  booed  on  it*  aoxt  rout*  point  •/ 
/•  ALGORITHM:  -  uaing  '.he  arctangent  function  calcnlot*  th*  angl*  froa  •/ 
/•  th*  horizontal  •/ 
/•  -  than  uoo  th*  eoain*  and  tin*  functions  multiplied  by  the  •/ 
/e  total  velocity  vectorc  to  find  th#  nov  volocity  voctors  •/ 
/♦  PASSED  VARIABLES  :  object. info  ♦/ 
/•  RETURIS :  non*  */ 
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I 


/•  GLOBAL  VARIABLES  PASSED:  >om  •/ 

/•  GLOBAL  VARIABLES  CBAIOED:  bon*  */ 

/*  FILES  R5AD :  non*  •/ 

/«  FILES  VRITTEI:  */ 

/•  HARDWARE  IfPUT:  non*  •/ 

/*  HARDWARE  OUTPUT:  con*  •/ 

/•  NODULES  CALLED:  non  a  •/ 

/*  CALLI1Q  NODULES:  evade,  updato.poaitlon  */ 

/*  ORDER  OF:  This  function  is  of  order  0(1)  */ 

h  AUTHOR:  Rob  Riiz*  */ 

/«  HISTORY:  non*  •/ 

. . ee.ee/ 


void  calc. curr .velocities  (object  .info) 

■tract  object. attributes  ‘object. info; 

{ 

■tract  location. type  enaxt. route. point  *  HULL; 

doubl*  delta.!,  delta.y,  delta.*,  tlop«.U|lt,  horisontal.eel.vector , 
t ia*. to. next. roat*. point ,  diotonce.to.next.reute.point ; 

if  (ll.isenpty  (obj*ct.info->roat*.dnta)  !■  TRUE) 

{ 

n«xt. root*. point  ■  (struct  location. type*)ll. pop  (object. lnfo->reute. data) i 
horizontal. vel.vector  ■  aqrt 

( <object_info->*elocity .x.velocity  •  object. info*>v*lecity .x.velocity)  ♦ 
(object. inf  o->velocit  y .  y.ve.locity  e  obj*ct .inf o~>velocity . y. velocity) ) ; 

delta. x  ■  next .route. peint->z. coord  -  obj*ct.inf o->locat ion . x.conrd ; 
delta. y  ■  uext_route_point->y_eoord  -  object. info->location.y_coord; 
delta.*  «  n«rt.,rout*.point->i.eoord  -  object. info->location .*. coord; 

elope. angle  *  a  tan  2  (delta. 7,  delta.x); 

diet ance.to.next.routa. point  *  eqrt  ((delta.*  *  delta.x)  ♦  (delta. y  e  delta. 7)) 
timo.to.rert. route. point  •  diatance.to.next. route. point  /  horizontal.val. vector 

objact,.info->velocity. x.velocity  ■  Horizontal. vel. vector  e  cos(alope. angle) ; 
object. info-ivelocity . y.velocity  •  horixontal.vel. vector  •  *in(*lope_angle)  i 
object. info~>v*locity.x_v*locity  »  delta.*  /  tine. to. nert. route. point , 

11. insert  (object. info->route_data,  next. rout*. point) ; 

) 

else 

{ 

object. info->v*locity .x.velocity  ■  0.0; 
object. inf*->velocity. y.velocity  *  0.0; 
object. info->velocity.z. velocity  "  0.0; 

> 

> 


. . . . ****************** . * . *** . ***/ 

/*  DATE:  W/06/S0  */ 
/•  VERSION:  0.0  */ 
/•  TITLE:  celc.tine.at.next.roatept  */ 
/*  NODULE. HUNBER:  2.4  •/ 
/•  DESCRIPTION:  Tbis  function  is  used  to  d*t*rnin*  the  tin*  at  the  next  */ 
/*  rout*point  based  on  tb*  dietanc*  travelled  and  th*  */ 
/•  current  velocity  */ 
/•  AI.GORITHN:  -  pop  th*  next  rout«point  off  th*  root*  data  queue  •/ 
/*  -  using  th*  standard  dietanc*  formla  b*t***n  2  points  0/ 
/♦  find  tho  distance  travelled  */ 
/*  -  calculet*  th*  totel  eeloeity  vector  •/ 
/•  -  tine  at  next  routepoint  *  distance  travelled  /  */ 
/*  total  valocity  vactor  ♦  curr.tine  */ 
/♦  PASSED  VARIABLES:  object. info  »/ 
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b  RETURIS:  doable  tiae.at.next.routept  •/ 
/•  GLOBAL  VARIABLES  PISSED:  bob*  */ 
b  GLOB1L  VARIABLES  CBAI6ED :  bob*  «/ 
b  FILES  READ:  bob*  */ 
/'•  FILES  WRITTEN  •  / 
b  HARDWARE  IIPUT;  BOBO  */ 
b  HARDWARE  OUTPUT:  aeae  0/ 
/♦  NODULES  CALLED:  bobo  0/ 
/*  CALLUS  NODULES:  update. position  0/ 
b  ORDER  OF:  Thiv  function  is  of  order  0(1)  */ 
b  AUTHOR :  Rob  lists  0/ 
b  HISTORY:  nano  e/ 
/«*♦**♦♦**♦♦*♦*♦♦*******♦*•••**•♦*♦***♦•♦•*****♦♦**•♦♦♦*♦•*♦*♦**•♦♦*♦*♦♦**♦♦/ 


double  cele.tiae.at .next. rot tvpt  (object. info) 
otruct  object. at trlbuteo  *object_iafoi 
( 

double  delta.!,  delta. y,  delta.*,  dlataBce.traeeled,  tiae.at.next.routept,  total. eel. vector: 
otruct  locet ion. type  *aext.routept  “  BULL; 
int  event; 

tine. at. next. roatept  •  object. infe-bcurrent.tiae; 
if  (ll.ieeapty  (object_info->routa_data)  !■  TRUE) 

{ 

next.routept  ■  (otruct  locet ion. type*)ll_pop  (object. info->route.deta) j 
Jelto. x  ■  object. inf o->locat ion. x.coord  -  next. routept->x. coord; 
delta. y  ■  object. info->location.y.coord  -  next.routept-iy.coord; 
delta.!  •  object. inf o->locat Ion. x.coord  *  ne*t_routept»>x_coerd; 

ll.ivteert  (object_itifo->ronte_data,  tiaxt.routupt)  ; 

distance.traveled  «  aqrt  ( (delta. x*delta.x>  ♦  <delta_y*delte.y)  ♦  (delta.zedeltn.i.))  ; 

total. vel.vector  ■  aqrt  ((object. info->velocity.x. velocity  e 
ob  ject_info->velocit)r.*. velocity)  + 

(object. info->veloeity . y.velocity  e  object. info->velocity.y. velocity)  ♦ 

(object. info->velocity  .(.velocity  *  object. infe->velocity. z.velocity)) ; 

if  (totel.vel. vector  !■  0.0) 

tiae.et.next.routept  ■  object. info~>current. bias  ♦ 
distance.traveled  /  total. vel.vector ; 
else 

tiae.at.next.routept  ■  object. info->current. tiae ; 

> 

return  tiae.at.next.routept; 

) 


/ . . . . 

b  DATE:  09/06/90  •/ 
I*  VERSIOI :  0.0  •/ 
/•  TITLE:  calc. tiae. at.nextnext.routept  •/ 
/v  MODULE. BUKBEA :  2.6  */ 
/*  DESCRIPTION  Thie  function  ia  uaed  to  deteraine  the  time  at  the  next  e/ 
b  routepoint  baeed  on  the  diate&ce  travelled  and  the  »/ 
b  current  velocity  */ 
b  ALGORITHM:  *  pop  the  next  routepoint  off  the  rente  date  queue  */ 
b  "  ueing  the  standard  distance  formula  betveen  2  points  */ 
b  find  the  distance  travelled  •  / 
b  -  calculate  the  total  velocity  vector  •  / 
b  -  tiae  at  next  routepoint  ■  distance  travelled  /  */ 
/♦  total  velocity  vector  •/ 
b  PASSED  VARIABLES:  object. info  */ 
/•  RETURIS:  double  tiae.at.next.routept  •/ 
b  GLOBAL  VARIABLES  PASSED:  none  •/ 
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/*  GL0B1L  VARIABLES  CRAIGED:  non*  ♦/ 
/♦  FILES  READ:  non*  */ 
/•  FILES  VRITTEI:  •/ 
/♦  HARDWARE  IRPUT:  non*  ♦/ 
/«  BARDVARE  OUTPUT:  non*  ♦/ 
/•  NODULES  CALLED:  non*  */ 
/*  CALLIIO  NODULES:  opdate.poeit  ion  •/ 
/*  ORDER  OF:  Tki*  function  in  ef  order  0(1)  */ 
/•  AUTHOR;  Rob  Rixxn  */ 
/♦  HISTORY:  non*  */ 
/e*eeeee***ee*eet*ee*e*»eeeeee*ee*e*ee*e**eeeeeee*e*e*e**ee«*e**eeoe***ee*e«/ 


double  calc.tiae.at.nextnext.rontept  (object. info) 
struct  object .attributes  *object.info ; 

{ 

double  delta.x,  delta. y,  delta.x,  diatanea.traeelad ,  tlna.at.next.routept ,  total. *<l.v*ctor 
struct  locat ion. type  enext.reutept  “  HULL,  enextnext.routept  •  HULL; 

Int  event; 

tin«.at.n*xt_rout*pt  *  object. info~>cnrrent. tine ; 

if  (ll.iesapty  (object. info->route.data)  !■  TRUE) 

( 

next.routept  ■  (struct  locat ion. type*)ll_pop  (objoct.info-lroute.dat*); 
delta.x  •  objact.info-Mocation.x.cooTd  -  n«xt.rout«pt“>x.coord ; 
delta. 7  ■  object. info->loc*tion. 7. coord  -  n*xt.rout«pt*>7. coord; 
delta. z  ■  object. info->location.z_coord  -  n«xt.rout*pt->x.coord; 

distance  .traveled  »  eqrt  ((delta. x«delta_r)  ♦  (delta.yedelts.y)  *  (delts.zvdelts.z!) ; 

total. »*l.**ctor  ■  eqrt  < (object. info->velocity . ». Telocity  * 
object. lnfo->velocity .x.velocity)  ♦ 

(obj*ct_info->**locit7 ,y. velocity  •  object. info->velocity . y. velocity)  ♦ 

(object. inf o-> velocity .x.velocity  •  ob j*ct. inf o->velo  icy  .  z. velocity) ) • 

it  (total. vel.vector  !■  0.0) 

tiae.at. next.routept  •  object. info->curr*nt.tin*  * 
distance. traveled  /  total.v*l.**ctor ; 
else  , 

t iwe. at. next.routept  »  object. info->curr*nt. tin*; 

> 

if  (ll.ieonpty  (objoct.info->route.deta)  !•  TRUE) 

{ 

nextn«xt.rout*pt  a  (struct  location.t7p**)ll_pop  (object. info->route_data) ; 
dulta.x  «  n*xt_rout«pt->x.coord  *  n*xtn*xt.reut*pt->x. coord; 
delta. 7  ■  next.routept-by.coord  *  »extnext.routept->y. coord; 
delta.!  ■  next. rout*pt->». coord  -  nextnext.rontept->x. coord; 

dietanc*. traveled  ■  eqrt  ( (delta. x*delta.x)  ♦  (d«lta.y*delta.y)  ♦  (Oelta.!«d*lta.s)) ; 

total. **l.eector  ■  eqrt  ((object. info->»*locity.x.»*locity  ♦ 
object. inf o->veloclty .x.velocity)  ♦ 

(object. info->»«locity  y. velocity  e  object. info->r*locity.y.»*locity)  ♦ 

(object. inf o->**locity . (.velocity  e  eb jec t. inf o*>veloc it y ,z. velocity)) ; 

11. insert  (object. info~>route.4ete,  nextnext.routept) ; 
ll.ineert  (object.info-bronte.dat*,  next .rout ept ) ; 

if  (totsl. eel. vector  !■  0.0) 

tiae.at.next.routept  •  tine.at. next. rout ept  *  dietonce.trseelod  / 
total.eel.eector ; 

else 

tiaa.at.next.routept  *  tine.et. next. rout ept ; 


return 

> 

if  <n«xt_rout«|>t  !•  HULL  II  n«ita«xt_rout*|>t  “»  BULL) 
n.in*«rt  (  ob  j  *c  t  _  inf  o->rout*. data,  n*xt .rent apt )  j 

raturn  tin*_at.a*xt_ro«t*pt ; 

) 


/v*************"****,*..**.****.*..***,,**.*,***,,..,,,. . . . . 

/•  DATE:  09/20/90  «/ 

/♦  VERS  1 01 :  0.0  ♦  / 

/♦  I  ITLE:  d*n*4«.*»***t»*at  »/ 

/•  H0DULE.1UHBER:  2.7  ♦/ 

/*  DESCRIPTION:  D*t«rnia«  *xt*nt  of  dui(«  «/ 

/•  Sch«dal«  appropriate  *v«nt  ♦  / 

/♦  ALGORITHM:  TBD  */ 

/*  ♦/ 

/•  •/ 

/•  PASSED  VARIABLES :  *?*nt_arg«  *«T«nt .argument  ♦  / 

/♦  RETURIS :  non*  ♦  / 

/♦  GLOBAL  VARIABLES  PASSED:  non*  ♦  / 

/♦  GLODAL  VARIABLES  CHARGED:  non*  •  / 

/♦  FILES  READ:  Ron*  ♦/ 

/*  FILES  VRITTEI:  non*  */ 

/*  HARDWARE  IIPUT:  non*  ♦  / 

/♦  HARDWARE  OUTPUT:  non*  ♦  / 

/•  MODULES  CALLED:  non*  */ 

/*  CAM. TIG  MODULES:  ordn*nti*_r*ach*d.targ*t  •  / 

/•  ORDER  OF:  Thi*  function  i*  of  ord*r  0(1)  •  / 

/•  AUTHOR:  Rob  Rina  •/ 

/*  HISTORY:  non*  ♦  / 

/t.*******^*******#********************************************************/ 

void  dta»g*_*as4ttn*nt  («v«nt.*rgun*nt) 
struct  *vant_args  **vont.argua*nt ; 

( 

t«r«inat*.ol>j*ct*  (***nt.argui»«nt) ; 

) 


/••••««»»*• a******************************************************** •••••»««•/ 

/•  DATE:  09/20/90  ♦/ 

/•  VERSIOI:  0.0  ♦  / 

/•  TITLE:  dif f*r*nc«.in.*ltitud«  •/ 

/*  MODULE. HUMBER:  2.8  */ 

/*  DESCRIPTION  D*t*r*in«»  tk«  diff*r*nc*  in  altitud*  of  tno  obj«ct*  */ 

/*  ALGORITHM:  D*t*rmin*  th*  cnrr«nt  altitnd*  of  tb*  object*  »/ 

/•  Raturn  tb*ir  diff«r*nc*  •/ 

/•  PASSED  VARIABLES:  *v*at.arg*  ***«nt.argua*nt  */ 

/*  RETURIS;  doubl*  diff*r*nco  or  0.0  ♦  / 

/•  GLOBAL  VARIABLES  PASSED:  non*  ♦  / 

/•  GLOBAL  VARIABLES  CBAIGED:  non*  •/ 

A-  FILES  READ:  bon*  */ 

/♦  FILES  VRITTEI:  non*  •/ 

/*  HARDWARE  IIPUT:  non*  ♦  / 

/♦  HARDWARE  OUTPUT:  non*  •  / 

/*  MODULES  CALLED:  non*  •/ 

/«  CALLMG  MODULES:  *«naor.ch*ck,  collision  diatanc*  r«ach*d  •/ 

/♦  ORDER  OF:  Thi*  function  is  of  ord*r  l)(l>  ♦  / 

/•  AUTHOR:  Rob  Rina  •/ 

/•  HISTCRY:  non*  •/ 

/«***»vv*****»*«v*****«vv«***»»******o****«******»**«*v«*«**v**v*** 
doubl*  diff *T«nc*.in_altitud*  (***nt_*rguM«ht) 
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(tract  event. ergs  (eveut. argument; 

{ 


doubl«  difference ,  curr.tine; 

etrr.tin  «  (f«u.trgoaat'>ob]«ctl->cimat.Ui<j 

if  ((difference  ■  fabe  (event. argnnent->ebjectl->location.z.coord  - 
(event_arguaent->object2->locetion.z.coord  + 

((curr.tiae  -  event  .argument ->object2->  current  .time)  • 
event.argpaeat->object2->velecity .(.velocity))))  <■  6.0) 
return  0.0; 
elso 

return  difference; 

) 


. . . . . . . 

/•  DATE:  08/13/90  »/ 
/(  VERS101 :  0.0  •/ 
/•  TITLE:  evade  ./ 
/•  MODULE.! UMBER :  2.9  e/ 
/•  DESCRIPTIO*:  Thie  function  is  need  to  reorient  and  change  the  velocity  */ 
/♦  vectore  of  a  vehicle  in  roaponae  to  it  turning  auay  from  a  •/ 
/•  threat  */ 
/♦  ALGORITHM:  -  calculate  or  determine  the  threat  vehicle >a  path  e/ 
/•  -  adjuat  your  path  to  be  90  degreea  fren  the  threat  path  •/ 
/•  noving  away  froa  the  threat  path  (/ 
/♦  PASSED  VARIABLES :  evader,  and  evaded  */ 
/•  RETURIS:  none  */ 
/•  GLOBAL  VARIABLES  PASSED:  none  e/ 
/•  GLOBAL  VARIABLES  CHARGED:  none  •/ 
/•  FILES  READ:  none  •/ 
/•  FILES  VRITTEI :  •/ 
/*  HARDWARE  IBPUT:  none  •/ 
/«  HARDWARE  OUTPUT:  none  •/ 
/•  MODULES  CALLED:  aend.(f)update,  add.new.routepoint  «/ 
/•  CALLIIG  MODULES:  operator. evaluation  •/ 
/*  ORDER  OF:  Thie  function  ia  of  order  0(1)  •/ 
/•  AUTHOR:  Rob  Rizza  •/ 
/•  HISTORY:  none  •/ 
. . . . * . . . . . . 


void  evade  (evader,  evaded) 

struct  object.attributea  (evader; 
struct  object.attributes  (evaded; 

{ 

int  is. rout apt .good  «  TRUE; 

double  evaded.slope,  evader. slope,  evaded. y. intercept ,  evader.y.intercept ; 
double  z.direction.indicator ,  y.direction_indicator,  eoamon_x.pt,  common. y.pt; 
double  elope.angle,  relative.poeition,  total.vel.vnetor ,  xl.temp,  yl.tenp; 
double  x2_temp,  y2_teup ,  delta.!,  delta.y,  diet!,  dist2; 

struct  location.type  enezt.routept  ■  HULL; 

total. vel.vector  ■  aqrt  ((evadera>>velocity . z. velocity  (  evader->velocit y . r.velocity)  + 
(evuder-ivelocity.y.velocity  e  evader-iveloeity .y. velocity)) ; 

if  (evaded->velodty .r.velocity  *■  0.0  At  evaded~>velocity.y_velocity  !■  0.0) 

{ 

relat ive.poeition  ■  evader-ilocation.x.coord  *  evaded-ilocation.x.coord; 

if  (relative.poeition  <  0,0) 

{ 

evader-ivelocity. r.velocity  ■  total.vel. vector  »  -1.0; 
evader-ivelocity.y.velocity  ■  0.0; 
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•xader->*alocity . z.valocity  “0,0; 


•xader-ioriantation.ya*  ■  270.0; 

•*ader->oriantation . pitch  ■  0.0; 

•*ader->orientation .roll  ■  0.0; 

} 

*ls« 

{ 

nul«->nlocit;.i.T«locitj  *  total.xel.xector ; 

•xnd«r->»elocity . y.xalecitj  ■  0.0; 

•xador-ixoloeity . x.xolocity  ■  0.0; 

e*a dar->oriantation.yaa  -  90.0; 
eradar-ioriantation. pitch  ■  0.0; 
exader->orientation . roll  ■  0.0; 

> 

add.nes.rontepolnt  (evader,  60.0); 

} 

else  if  (axadad->valocity .y.xelocity  ««  0.0  kk  exaded->velocity . x.xelocity  !  =  0.0) 

{ 

relative. posit  ion  *  evader->locat  ion .  y.coord  -  exadod-Olocation .  y.coord; 

if  (relative.position  <  0.0) 

{ 

evader->*elocity.x_valoeity  ■  0.0; 

«vadar->velocity . y.valocity  *  total.xel.xector  *  -1.0; 
avadar->xelocity. x.xelocity  *  0.0; 

evadcr->orientation. ynn  ■  180.0; 

•vader->criantation . pitch  ■  0.0; 

•vader->oricntation.roll  -  0.0; 

} 

•Isa 

{ 

exadei->xelocity. x.xelocity  a  0.0; 

•xader->xelocity. y.xelocity  ■  total.xel. factor; 

•xader-ixolocity . z.ta] ocity  ■  C.O; 

•vader->orientation.yax  *  0.0; 
axader->orientation. pitch  “  0.0; 

•xader->orienteticn.roll  ■  0.0; 

1 

adi.nax.  routapoint  (exedar,  60.0); 

) 

•Isa  if  (axaded->xel,jcr,.y.x.\'eliicity  ■■  0.0  tl  exadad->xelocity .y.xelocity  =»  0.0) 

{ 

delta.!  a  exadar->locetion .x. coord  -  exaded->locet ion .x.coord; 
delta. y  ■  exeder->locetion.y. coord  -  «Ttd«d->location  y.coord ; 

•lopa. angle  ■  at an?  ((daite.r  •  *1),  delta. y) ; 

il.taap  ■  ex«d«r->locttlon .x. coord  a  (10  a  coa  (slope. angle))  ; 
yl.teap  ■  «xedar->locat ion .y .coord  ♦  (10  a  sin  (slope. angle)) ; 

x2_teap  ■  exeda»->loc»tioi.  .x.coord  -  (10  •  coe  (slope. angle))  ; 
y2_teap  «  exedar ->location .y.coord  -  (13  a  sin  (slopa.angla)) ; 

noxt.rontapt  ■  ll.pop  (exader->ronte_data) ; 

if  (,-qrt  (  (next .rout ept->x_coord  -  nxedad->locat  ion  .x.coord)  • 

(noxt.ront.ept-.' x.coord  -  avaded->loc  at  ion.  x.coord)  ♦ 

(nett_rontept->y_coord  -  axaded-»ocation. y.coord)  • 

(next.routept->y_coord  -  •▼adad->locat ion  y.coord))  <m 
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(double)get. tensor. range  (evader)) 

{ 

is.routept.geod  ■  FiLSE; 

if  (ll.iaanpty  (evadar->roate.data)  !•  TRUE) 

{ 

next.rontept  •  ll.pop  (evader-rronte.dat a) ; 
ia.rontapt.good  m  TRUE; 

> 

) 

xl.teap  ■  il.tMp  -  next_rontept->x.coord; 
yl.taap  ■  yl.taap  -  next_rontept-> y.coord; 

x2_teap  ■  il.taip  -  next_rontept->x_coord; 
y2.tenp  ■  yl.taap  -  rext.rontept-iy.coord; 

diatl  -  aqrt ((xl.teap  a  xl.teap)  *  (yl.taap  *  yl.taap)); 
diet  2  ■  aqrt ( (x2_tenp  a  x 2 _ t vxrp )  ♦  (yl.taap  *  y2_t aap)); 

if  (diatl  <*  lifts) 

( 

evader->velocity. x.velocity  ■  total.val.vactor  •  cob  (alopa.angle); 
evader->velocity.y. velocity  ■  total.val.vactor  *  air  (elope.tngle) ; 
evader->velocity.i_veloeity  «  0.0; 

} 

also 

( 

evadar->velocity. x.velocity  ■  total.val.vactor  a  cob  (alopa.angle)  *  -1; 
«vader->v«locity.y .velocity  a  total.val.vactor  •  air  (alopf.anglo)  *  -1; 
evader->velocity .2. Telocity  "0.0; 

) 

if  (is.routopt.good  ««  TRUE) 

ll.inaart  (•»»d*r->roata.d'»t« ,  naxt.routept)  ; 
add.nes.routepoint  (aaadai,  60.0); 
calc.curr.orientation  (evader) ; 

) 

also 

( 

evadad.elopa  *  evaded->velecity .y.velocity  /  evaded->valocity. x.velocity ; 
evaded. y. intercept  *  evaded->locat ion . y.coord  -  (evaded. alope  a 
evaded->locat ion. x.coord) ; 

evador. alopa  ■  -1  /  ovadad.alopa ; 

evador. y. intercept  “  avader->location. y.coord  -  (evader.alepe  * 
evadar~>location. x.coord) ; 

coaaon_x.pt  ■  (evaded. y  .intercept  -  evader. y. intercept )  /  (-1  a 
(evaded.alopa  -  evader. elope) ) ; 

coxaion_y.pt  •  ovadad.alopa  a  coaHOn_x.pt  ♦  evaded. y.intercvpt ; 

x. diraction.indicator  ■  evader->locat ion. x.coord  -  coMos_x.pt; 

y. diraction. indicator  ■  avader-»ocation. y.coord  -  ceaBon_y.pt; 

alope.angle  ■  at an  (evader.alepe) ; 

evader->veloclty .x.velocity  ■  fabs  (total.val.vactor  e  cob  (ilope.angle)) ; 
ovader->7olocity . y.velocity  •  I aba  (total.val.vactor  e  a in  (elopa. angle) ) ; 
evader->velocity .x.velocity  -0.0; 

if  (x.diraction.indicator  <  0,0) 

evader->velocity .x.velocity  ■  -1  a  aveder->velo:ityx. velocity; 

if  (y.diraction. indicator  <  0.0) 


A-21 


e»ade*->eelocity.y..»elocity  »  -1  *  e**d*r->Y*locit y .y.Telocity; 

Jdd.new.rout epoint  (evader ,  60.0); 
calc.curr.orientation  (etader); 

} 

send.fupdete  (evader) ; 

> 


. . . 

/♦  DATE:  09/30/90  ♦/ 

/•  VERSIOI:  0.0  ♦  / 

/♦  TITLE:  get. sensor .rang*  ♦/ 

/•  MODULE.!  UMBER:  3.10  •/ 

/•  DESCRIPTION:  This  f auction  io  aood  by  sensor.check  to  detemlne  the  »/ 

/*  tango  of  tho  aonoor  being  ustd  */ 

/•  ALGORITHM:  For  as  »any  iteas  that  thara  aro  in  tho  aonsor  list  «/ 

/•  -  chock  tho  aonoor  range,  »a»o  tho  largest  range  found  */ 

/«  -  return  tho  range  found  »/ 

/•  PASSED  VARIABLES:  atruct  object. attributes*  object. info  */ 

/»  RETURIS:  range  */ 

/»  GLOBAL  VARIABLES  PASSED:  none  ♦  / 

/•  GLOBAL  VARIABLES  CBAIGED:  none  •  / 

/•  FILES  READ:  none  */ 

/*  FILES  URITTEI:  none  */ 

/•  HARDWARE  IIPUT:  none  •/ 

/*  HARDWARE  OUTPUT:  none  »/ 

/•  MODULES  CALLED:  none  »/ 

/*  CALLIIti  MODULES:  sensor. check  */ 

/*  ORDER  OF:  This  function  is  of  order  0(n)  share  n  is  the  nunbsr  of  sensors*/ 

/•  AUTHOR:  Rob  Rizza  •/ 

/*  HISTORY:  none  •/ 

/ . * . . . . 

int  get.sensor.range  (object. info) 
struct  object. attributes  eobject.info ; 

< 

int  i,  length,  range  «  B33.  ten^.ranje  ■  0;  /*  default  sensor  range,  approx  1/2  mile  */ 

struct  sensors  eeeneor  *  HULL; 


if  (object.info-isensors  !“  BULL) 

{ 

length  •  11. length  (object.info-isensors) : 

for  (i  »  1;  i  <■  length;  i**) 

< 

sensor  ■  (struct  s*nsors*)ll_pop  (object. inf o->eeneors) ; 
if  (aensor->range  >  range) 
range  ■  sensor->range; 

11. insert  (object.info-isensors,  sensor); 

) 

> 

) 

else 

if  (object. info->object.tjpe  *“  HISSLE) 
range  ■  0; 

return  range; 

) 


. . ***** . . . . 

/♦  DATE:  09/20/90  •/ 

/*  VERSIOI:  0.0  »/ 

/•  TITLE:  hit.niso 

/•  MODULE. IUMBER :  2.11  »/ 
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/*  DESCRIPTIOI :  Dat«ninat  if  a  hit  or  ala*  take*  (lac*  •/ 
/*  ALGORITHM:  If  '  h*  obj*ct*  com*  within  a  ap*cifi*d  diataan*  •  / 
/*  schedule  a  d*a*g«.*a**aaB*nt  e/ 
/*  Bla*  »/ 
/»  call  a«nsor.ch«ck  */ 
/•  PASSED  VAklABLES :  *v*nt_*rg*  e***nt_*rgn»*nt  */ 
/♦  RETURIS :  non*  •/ 
/•  OLOBAL  VAklABLES  PASSED :  nona  */ 
/»  GLOBAL  VAklABLES  CHAIBED:  non*  */ 
/•  FILES  BEAD:  non*  •/ 
/•  FILES  VkITTSI:  non*  t/ 
/•  BABOVAkS  I SPOT:  non*  •/ 
/•  HARDWARE  OUTPUT:  non*  */ 
/•  NODULES  CALI, ED :  non*  »/ 
/•  CALLIIO  NODULES:  ordnac*_r*ach*d_t*rg*l  »/ 
/*  ORDER  OF:  Thia  function  ia  of  ord«r  0(1)  »/ 
/*  AUTHOR:  Rob  Rizza  •/ 
/»  BISTORT:  non*  */ 

/••••••••••••♦•♦••♦•••••a***** . ****♦♦*♦♦.*♦*♦..♦*»*.*«.*♦. . . 


void  hit.uisn  (event .argument ) 
struct  **snt_*rg*  4*v«nt_«rgua*nt j 
{ 

if  (fab*  («v*nt„argiUMnt->obj«ctl->locatlon.z_coord  - 
event_»rgin*«nt->obj*ct2->loc»tion.»_coord)  <■  10.0  AA 
fabs  (*v*nt_*rgua*nt->obj*ctl->loe*tion.y_coord  - 
*vent.argiu**nt->obj*ct2->location.y_coord)  <■  10.0  AA 
faba  (•**nt.argua*nt->obj*ctl->loc*tion.z_coord  - 
ev«nt_*rgum*nt->obj*ct2->location ,z_ coord)  <■  10.0) 
d<unag«.*8s*aan*nt  (**«nt_*rgun*nt) ; 

•Is* 

sensor.chack  («v«nt. argument ) ; 

> 


/..a..,...* . / 

/•  DATE:  09/20/90  */ 

/*  VERSIOI ;  0.0  */ 

/*  TITLE:  lina.of.aight  »/ 

/♦  NODULE. BUHBER:  2.12  •/ 

/•  DESCBIPTIOI:  Thia  function  ia  na*d  by  a*naor.ch*ck  to  datanln*  if  an  */ 

/•  unobstructed  lin*  of  sight  oziata  b*t***n  t*o  objects  */ 

/e  ALGORITHN :  TBD  */ 

/•  */ 

/•  */ 

/*  PASSED  VARIABLES:  struct  •v«nt_«rga>  event. argument  */ 

/e  RETURIS:  0,  1  */ 

/•  GLOBAL  VARIABLES  PASSED:  non*  »/ 

/*  GLOBAL  VAklABLES  CBAf BED :  non*  •/ 

/*  FILES  READ:  non*  •/ 

/*  FILES  VRITTEI :  non*  */ 

/*  BARDWARE  IIPUT:  non*  */ 

/*  BARDWARE  OUTPUT:  non*  */ 

/*  NODULES  CALLED:  non*  •/ 

/•  CALLIIO  MODULES:  s*n*or.<h«ck  •/ 

/*  ORDER  OF:  This  f auction  is  of  ordsr  0(1)  */ 

/*  AUTHOR:  Rob  Rizza  */ 

/•  BISTORT:  non*  »/ 

. . * . . . * . . 

int  line. of .night  (*v*nt_argua*nt) 
struct  ***nt.args  «*v*nt.*rgun«nt; 

{ 

return  1 ; 

} 
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. . . . . 

/♦  DATE:  09/30/90  */ 

/♦  VERSIOI :  0.0  •/ 

/*  TITLE:  on.collision.couraa  */ 

/»  NODULE.BUMBER :  2.13  •/ 

/*  DESCRIPTIOB:  DttmiiMi  vhclhtr  tie  ebjeeti  ilU  occupy  the  tut  */ 

/*  location  at  the  im  time  ♦/ 

/*  ALGORITHM:  Determine  if  the  object*  will  occupy  the  same  petition  at  the  */ 
/*  ine  tUe  */ 

/♦  Return  TRUE  if  true  */ 

/•  Else  retun  FALSE  */ 

/*  PASSED  VARIABLES:  event. urg*  *event .argument  */ 

/•  RETURIS:  TRUE  or  FALSE  */ 

/*  GLOBAL  VARIABLES  PASSED:  none  */ 

/*  GLOBAL  VARIABLES  GRAIOED :  none  */ 

/*  FILES  READ:  none  «/ 

/*  FILES  VRITTEI:  none  */ 

/•  HARDWARE  IBPUT:  none  */ 

/♦  HARDWARE  OUTPUT:  none  */ 

/•  NODULES  CALLED:  none  e/ 

/•  CALL1IG  NODULES:  e/ 

/*  ORDER  OF:  Thia  function  is  of  order  0(1)  e/ 

/*  AUTHOR:  Rob  Rizza  */ 

/•  BISTORT:  none  e/ 

. . . . tee . . . . . . 

int  on.colliaion.courae  (event.argument) 
struct  event.args  eeeent. argument ; 

( 


double  diff.in.eurr.r.eoorda,  diff.in.curr.y.coorda,  diff.in_curr_z.Tela, 

diff.in.curr.y.vels,  a,  b,  c,  ten. under. radical,  tiae.at.next.routeptl , 
tima.at.next.routeptT,  aenaor.contact.tima,  curr.time; 

curr.tiue  *  event_argument->objectl->current_time; 

diff.in.eurr.r.eoorda  ■  evont_arguuent->objectl->lccation.x_coord  - 
(event_argument->objact2->location.x. coord  * 

((curr.tiue  -  event_argument->objecl2->current_t  ime) 

•  event .argument ">object2~> velocity . x.veloeity) ) ; 
diff.in.curr.y.coorda  ■  event.argumentOobjectlOlocat ion. y. coord  - 
(* vent .ergu»ent->ob ject2->locat ion . y.coord  ♦ 

((curr.tiue  -  event_arguuent->object2->current.tiao) 

*  event. arguuent->object2->velocity.y_valocity)) ; 

diff_in._eurr_x.vela  ■  event. arguuent->objectl->velocity .x.veloeity  - 
event _arguaent->object3->velocity .x.veloeity; 

diff_in.curr_y.vela  ■  event.arguaent->objecti->velocity .y.veloeity  - 
event .argument 'iobject  2->valocity . y. velocity ; 


/****••*•••*  QUADRATIC  EqUATIPI  IS  <t):  t  »  <-b  ♦-  iqrt  (bb  -  4ac))/2a 

a  »  (diff.in.curr.x.vela  •  diff.in_curr_x.vels)  ♦ 

(diff.in_eurr.y_ vela  a  diff.in.curr.y.vels) ; 
b  -  (2.0  •  diff.in.eurr.r.eoorda  diff.in.curr.x.vela)  ♦ 

(2.0  e  diff.in.curr.y.coorda  e  diff.in_eurr_y.vela) ; 
c  *  (diff.in.curr.x.eoorda  a  diff.in.curr.x.coorda)  ♦ 

(diff.in.curr.y.coorda  a  diff.in.curr.y.coorda); 

term. under. radical  ■  (b  *  b)  -  (4,0  •  a*  c) ; 

if  (fabs  (term. under. radical)  <  0.0001) 
torm.under.radical  ■  0.0; 
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if  (term.under.radical  ••  0.0  it  diff erence.in.altitude(eveBt  argument)  0.0) 

{ 

t ime.at. next .rout apt  1  ■  calc.t ise.at .neit.routapt  (event. arguaent-hobjectl) j 
t  ime.at. aeXt_routept2  ■  calc. tine. at.next.rontept  (event. arguBent->object2) ; 

sensor.contact.tiae  ■  <-J  *  b  -  eqrt  (ter*. under. radical))  / 

(2.0  •  a)  ♦  event. erguBcat->objectl->current_tiae; 

if  (aensor.cantact.tine  <■  tine.at.next.routeptl  it 
sensor.contact.time  <•  tiae.at_naxt.routept2) 
return  HUE; 

> 

return  FALSE; 

> 


e.eeeee.eeee* . . . . . . . 

/♦  DATE:  O9/30/9O  »/ 
/•  VERSIOI :  0.0  */ 
/•  TITLE:  on.target.liat  */ 
/*  MODULE.  IUMBER:  2.14  •/ 
/*  DESCRIPTION  Determines  whether  an  object  is  ob  another  object’s  target  •/ 
/•  list  •/ 
/■»  ALGORITHM :  Search  an  object’s  target  list  for  the  other  object  »/ 
/•  Return  TRUE  if  found  »/ 
/•  Else  return  FALSE  */ 
/♦  PASSED  VARIABLES:  object .attributes  eobjectl ,  object. attributes  eobjectl  e/ 
/»  RETURIS:  int  TRUE  OT  FALSE  •/ 
/♦  GLOBAL  VARIABLES  PASSED:  aone  •/ 
/•  GLOBAL  VARIABLES  CHARGED:  none  e/ 
/e  FILES  READ:  aone  e/ 
/•  FILES  WRITTEI :  none  e/ 
/*  HARDWARE  IIPUT:  none  e/ 
/*  HARDWARE  OUTPUT:  none  e/ 
/e  MODULES  CALLED:  none  e/ 
/♦  CALLIIG  MODULES;  */ 
/•  ORDER  OF:  This  function  is  of  order  0(r.)  share  n  is  the  number  of  */ 
/*  targets  in  the  objects  target  list  •/ 
/*  AUTHOR:  Rob  Rizza  */ 
/♦  HISTORY:  none  */ 
. . . . a . . . . 


int  on.target.list  (objectl,  object2) 
struct  object. attributes  eobjectl; 
struct  object. attributes  eobject2; 

{ 

int  nua.targeta,  i,  return. value  ■  FALSE; 
struct  targets  etargat; 

if  (objectl->target_list  ! “  HULL) 

{ 

nun.targata  ■  11. length  (objectl-htarget.list) ; 

for  (i  •  1;  1  <■  sum. targets;  i++) 

{ 

target  •  ll.pop  (objectl *>target. list) ; 

if  (target-itarget.tvpe  »  objsct2->objeet_type) 
return.value  »  TRUE; 

11. insert  (objectl-itarget.liat ,  target); 

} 

) 

return  return.value; 
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) 


/♦  DATE:  09/30/90  */ 
/«  VERSIOB :  0.0  •/ 
/*  TITLE:  operator.evsluation  */ 
/*  NODULS.BUHBER:  3.16  »/ 
/•  DESCRIPTION  Dtt«niMt  th«  Mtt  ctUH  of  action  for  u  objoet  ikich  »/ 
/*  boo  sensod  oaotbor  objloct  •/ 
/•  ALOORITDI :  ooo  cooo  ititwnt  below  */ 
/•  PASSES  VARIABLES ;  event. ergs  eevsnt. argument  */ 
/♦  RETURIS:  none  */ 
/♦  GLOBAL  VARIABLES  PASSED:  Bone  */ 
/♦  GLOBAL  VARIABLES  CHARGED;  none  e/ 
/e  FILES  READ:  none  */ 
/•  FILES  VRITTEI :  nono  e/ 
/»  HARDWARE  IRPUT:  none  •/ 
/*  HARDWARE  OUTPUT:  none  »/ 
/«  MODULES  CALLED:  none  e/ 
/*  CALLIIQ  NODULES:  e/ 
/*  ORDER  OF:  Thin  function  ie  of  order  0(1)  e/ 
/»  AUTHOR:  Rob  Riszn  */ 
/*  HISTORY:  none  •/ 
. . eeeeeeeeeeee,eeeeeeeee.ee.eeeeeeeeeeeeeeeee..*ee.eeeee.eee..ee*.e...*./ 


void  operator. evelnntion  (event. ar(,unent) 
etruct  event .urge  *event. argument ; 

( 

struct  object. attributes  ‘observer  ■  BULL; 
struct  objeet. attributes  eobeerved  ■  BUU.; 
int  event,  senaor.range.obacrver ,  sensor. range. observed ; 

if  <event.argUHcnt->objectl  !■  BULL) 
observer  •  event. srgu»ent->objectl ; 

if  (event.argnaaent->ol.ject3  !■  BUU.) 
observed  ■  event .argument ->objec t3 ; 

seneor.range.observer  ■  get. sensor. range  (observer); 
sensor. range .observed  »  get.aensor. range  (observed); 

if  (observed->object.t ype  HISSLE) 

event  ■  OiOO;  /e  do  nothing  */ 

else  if  ((observer->objeet. loyalty  ••  ebserved->objvrt.l«yelty)  RA 
(on.colliaion.courso  (ovont.argunent )  ■■  FALSE)) 
ovont  •  OiOO;  /o  do  nothing  */ 

olso  if  ((obscrver->ebjact.loyalty  ■“  observed->objoct.loyalty)  II 
((on. collision. courso  (ovsnt.argunont))  *•  TRUE)) 
ovont  ■  OrOl ;  /•  ovade  •/ 

alee  if  ((obsorver->vL ject.loyalty  !•  obsorvod*>ob joct. loyalty)  IR 
(sensor. range. observer  >  censor. range. observed)  tl 
(on. target. list  (observer,  observed)  ““  FALSE)) 
event  ■  0x01 ;  /e  evade  •/ 

elee  if  (obaerver->vbjeet.loyelty  !•  ob»erved->object_loyalty  AA 
(on.targst.list  (observer,  observed)  *•  TRUE  II 
sanaor.rsnge.observer  <■  sensor. range.obaerved) ) 
event  ■  OrlO;  /•  attack  e/ 
switch  (svent) 

< 

case  OiOO: 
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break ; 


case  OtOl: 

( 

/•  put  in  cod*  to  aahe  aura  next  roatopt  it 
not  eithin  senior  rang*  of  the  at  at  ionary 
object  being  avoided  ♦/ 

evade  (observer,  observed); 

broak ; 

> 

cast  OxlO: 

attack  (event  .axgoaent ) ; 

) 

> 


/••♦♦♦♦♦♦♦♦♦•••♦♦•••♦•♦•♦♦♦•♦♦•♦•♦♦•••♦••♦♦♦♦♦•♦•♦•♦•♦♦•♦♦••at***  »•♦♦•**•♦ 

/♦  DATE:  08/31/90 
/*  VERSIOI :  0.0 
/«  TITLE:  read.dstfile 
/•  HODULE.IimBEft:  2.16 

/*  DESCRIPTIOI :  This  function  it  uatd  to  road  tho  tcanario  data  fron  file 
/♦  ALGORITHM:  *  vhile  the  pointer  hat  not  ranched  the  end  of  file 
/•  -  read  in  a  line 

/*  -  aeaign  the  data  to  it  appropriate  field 

/*  -  arite  the  icon  identifying  info  to  the  diaplay  file 

/«  PISSED  VARIABLES:  path 

/•  RETURNS :  etruct  linked.liate  aaster.obj.list 
/•  GLOBiL  V AM 4BI.ES  PASSED:  none 
/•  GLOBAL  VARIABLES  CHAIOED;  none 
h  FILES  REiE .  none 
/♦  FILES  WITTER : 

/•  HARDWARE  IRPUT;  none 
/»  HARDWARE  OUTPUT:  none 
/♦  HODULES  CAIXFD:  none 
/•  C4LLIIG  HODULES:  aain 

/•  ORDER  OF:  Thie  function  ie  of  order  0(n)  aharo  n  ia  the  number  of  lines 
/•  in  the  file  being  read 

/»  AUTHOR:  Rob  Rina 
/•  HISTORY:  none 

. . . . . . . . . . 

toid  read.dat  efile  (path) 

Char  epath; 

{ 

FILE  eptr.to.datafile,  eptr.to.diepley.file; 


'♦/ 

♦  / 
*/ 
•/ 
•/ 
♦/ 
•/ 
♦/ 
♦/ 
•/ 
»/ 
•/ 
•/ 
•/ 
•/ 
*/ 
•/ 
*/ 
•/ 
•/ 
•/ 
*/ 
*/ 
♦  / 
>•/ 


extern  etruct  linked. lie*  vaaster.obj.liet ; 
ertern  int  higheat.obj.id; 

struct  object. attributes  ‘object  •  HULL; 

struct  locat ion. type  eroutept  “  HULL; 

struct  sensor a  *aansor  “  HULL; 

struct  targata  atargat  v  IULL: 

struct  araaaenta  earaaaent  ■  HULL; 

struct  defeneive.eyeteae  ‘defensive. eye tea  *  IULL; 

int  i,  fields,  nua.fielda,  lina.nua  •  0,  nua.routepva  ■  0,  nua.targete  a  0; 
int  nua.aenaors  ■  0,  nua.araaaenta  *  0,  nua.def ‘naive. systems  «  0,  object. type; 

char  line [400]  ,  ‘ptr.to.line  ■  HULL; 
char  eteap.ptr  ■  IUU. ; 
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if  ((ptr.to.datafila  »  fopan(path,  "r">)  !■  HILL) 

{ 

uhll*  (tfoof  (ptr_to_4at*f ilo>) 

( 

if  (tgota  (lino,  400,  rtr.to.datafilo)  «•  IULL) 
brook : 

if  ((objoct  *  (struct  objoct. attribntoo*)aslloc 
(oizoof (itract  objoct.attribatoa)))  !■  IULL) 

( 

OOllnO.BUn; 

obj*ct->objaet„typ«  *  atoi  (atrtok  (lint,  “  "))j 
objoet->objoct.id  •  atoi  (atrtok  (IUU,  "  ">)i 
objoct->objoct.loyalty  ■  atoi  (atrtok  (IUU.,  "  “  )); 
objoct->currotit.tiiM  •  atof  (atrtok  (IUU.,  "  "))j 
obj«ct->fa«l.otataa  •  atoi  (atrtok  (IUU.,  "  ")); 
objoot'Xoadition  *  atoi  (atrtok  (IUU,.  "  ")); 
obj«ct->»ulnorabliity  ■  atoi  (atrtok  (IVLL,  '*  *')); 
obj*ct->location.x.coord  ■  atof  (atrtok  (IULL,  11  ")); 
obj»ct~>ioc*tion. j. coord  «  otof  (atrtok  (IULL,  "  ">>; 
obj*ct*>locatlon.i. coord  •  atof  (atrtok  (IUU.,  "  ")). 
objocWralocity.s.ralocitj  •  atof  (atrtok  (IULL,  “  ")>; 
objscWoolocity.y.valocity  •  atof  (atrtok  (IULL,  "  •’>); 
objact->»alocity.x..»*locity  ■  atof  (atrtok  (IULL,  “  •')); 
objoct->rotation.ya«_rato  ■  atof  (atrtok  (IULL,  "  ”)); 
obj*ct->rotatioo.pitch.rat«  «  atof  (atrtok  (IUU.,  '•  ")>; 
objoct“>rotation.roll_rato  ■  atof  (atrtok  (IULL,  "  M)); 
obj*c<'->op*rstor.«rp«rioBc*  ■  atoi  (atrtok  (IULL,  "  **> > ; 
obj«ct*>op»rator . throat .kaoalodg*  •  atoi  (atrvok  (IULL,  "  ")); 
objoct'>p«rforawc«  ntn.turn.radiuc  *  asoi  (atrtok  (IULL,  "  ••)); 
objact->p«rfoniaiu:o.aa*.apaa<l  •  atoi  (atrtok  (IULL,  "  ’’)); 
ohj«ct->p*rforwancs.a*a.fu#l_con*_rat«  •  atoi  (atrtok  (IULL,  "  ")) 
objoct->p*rf oraanco .aar.ci iab.rato  a  atoi  (atrtok  (IULL,  "  ">); 

nu».rout«pto  »  atoi  (atrtok  (IULL,  "  ")); 

objoct'>ronto_data  «  ll.aaks  (LIFO); 

for  (i  «  1;  i  <■  Bua.routopta;  !♦♦) 

( 

if  ((routopt  "  (struct  locat ion_typ*»)a»lloc 
(sizoof (struct  location  typo)))  !■  IULL) 

( 

routopWz.coord  ■  atof  (strtck  (lULt.,  "  ")); 
rout*pt->y„coord  •  atof  (atrtok  (IULL,  "  ")); 
rout*pt->z..coord  •  atof  (atrtok  (IULL,  11  ")); 

ll.insart  (objact-irouta.data,  root apt), 

} 

olaa 

printf  ("CillOT  kStD  II  kOUTEFuIlTS,  I0T  EIOUOI  MEHOdYW) ; 

> 

if  ((ntw.t tasors  ■  atoi  (atrtok  (IULL,  "  ”)))  >  0) 

r 

\ 

objact~>ssBscr*  ■  ll.aako  (FIFO); 
for  (i  •  1;  i  <■  naa.ionsora;  loo) 

( 

if  (<*OBsor  *  ('tract  staaora*) 

■alloc (aiiaof (struct  ooaaors)))  !■  IULL) 

{ 

»«n*or->typa  ■  atoi  (otrtok  (IULL,  ••  ")); 
oonaor->ranga  •  atoi  (atrtok  (IULL,  "  ")); 
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»enoor“>roool«tion  »  atoi  (atrtok  (IULL,  "  "))j 

D.inaart  (objact->santora ,  unior); 

> 

•laa 

pi  lMf  C'CAIIOT  »F*D  It  S8IS0M,  I0T  EI0U0I  ICTORYW1) ; 

) 

) 

•lM 

objact->aaasora  •  IWAi 

if  ((Mua.anMwanta  •  atoi  (atrtok  (IULL,  "  •')))  >  0) 

( 

objact->nwiaatanta  •  H.aaka  (FIFO)  j 
for  (i  •  i;  i  <»  naja.araaaanta ;  it+) 

{ 

if  (<ar»n»ant  •  (struct 

malloc ( ai xaof ( a t ruct  mauintf)))  !■  IULL) 

{ 

arosaant ->t jpa  •  atoi  (atrtok  (IULL,  "  "))i 
araaa»nf>ranga  »  atoi  (atrtok  (IULL,  "  ")): 
nmatant-Hathnlity  ■  atoi  (atrtok  (IULL,  "  ")); 
«raii»ant->acctiracy  •  atoi  (atrtok  (IULL,  M  ")); 
arnaaant-Xpaad  ■  atoi  (atrtok  (IULL,  "  ")); 
arnaaont-kcount  ■  atoi  (atrtok  (IULL,  “  ”>); 

U.inaart  (ob  jact-Xnaaaarvta ,  arautant); 

> 

•  Isa 

,-iii.U  ("OillOT  RKAU  II  AMUHUTS,  lot  EIOUOI  KKHOKYV) . 

) 

} 

•  Isa 

obj*ct->ar»*»antn  »  IUU,; 

if  (( non. t argot  a  *  atoi  (atrtok  (IULL,  "  "))>  >  0) 

( 

objact'ktargat.Xiat  *  ll.aaka  (FIFO); 
for  (i  •  1;  i  <•  nua.targata;  i*+) 

( 

if  ((targot  •  (atruct  t4rgata*)«alloc(a  i*oof(»tr\Kt  (argots))) 
•*  IULL) 

( 

t«rgat->targai_typa  ■  atoi  (atrtok  (IULL,  “  ")); 
t»rgat->targat_location . t .coord  •  atof  (atrtok 
(IULL,  "  ’•)); 

targ«t->tar*at. location  y. coord  a  atof  (atrtok 
(IUU,  "  ")); 

targ«t->targat„location  x.coord  ■  atof  (atrtok 
(IUU..  ••  ")); 

ll.inaart  (objact-ktargat.liat ,  targat); 

) 

alaa 

printf  C'CAIIOT  HID  II  TAkGETS ,  I0T  KIOUCH  NEMORYXn")  ; 

) 

> 

•Isa 

obj ict->targat_liat  ■  IULL; 
taap.ptr  *  atrtok  (KILL,  "  ") ; 
if  (t«s\f>.ptr  •  »  IULL) 
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print!  ("BOGUS  OAT*  I>  UIK  Xd  OK  IIPUT  DATAFILEV ,  line_uv»); 

if  ((n<m.defeAtita..«7tt«aa  •  atoi  (taap.ptr))  >  0) 

{ 

object->defanti»a_*yttem*  *  H_»nV«  (FIFO); 

Tor  (1  *  tj  1  <■  ntia.daftntit a.tyattaa ;  i**) 

{ 

IT  ((dtfaAii»a_#7#tt*  •  (atrtct  defaaaive.tyttetta*) 
atllocCaitaof  (atmct  dafenaiya.ayataaa)))  )•  BULL) 

( 

deieaaivt.tyatMrbtypa  •  ttoi  (atrtok  (IULL,  "  ">)[ 
defeh*lYt.*y*ta»->rkAg«  ■  atoi  (Atrtok  (IULL,  "  ")); 
taap.ptr  «  itrtok  (IULL,  11  "); 

It  (tamp.ptr  ••  IULL) 
prlntf  ("BOOUS  DAT*  !■  LIIK  *d  OF  IIPUT 
D*TtPI«.E\n" .  lino.nua); 

0efenalTe.ajataii->4f  fectirenaea  »  atoi  (teap.pti.), 

11. intort  (objact'KWfantiaa.eyttama ,  dafantita.tyatan) ; 

) 

elaa 

|>rintt  ("CAIIOT  ROAD  II  DKFKISIVK  SYSTEMS , 

IUT  KIOUGH  MENORYln") ; 

) 

) 

else 

objtcWdafei.eiae.ayitamn  •  IUU.; 

if  ( (ptr.to.diaplar.f ilt  “  fopen  (“diaplay .c" ,  "»"))  !»  IULL) 

< 

fprintf  (ptr.to. diaplay. f  tit ,  "SO  Xd  Xd\n", 
object*>objact_id,  objact->objact_typa) ; 
fclota  (ptr.to_ditplty.filt) ; 

11. intart  (■aatar.obj.liot ,  objact); 

) 

4l>« 

prlntf  ("CAIIOT  OPEI  DISPLAY  FILE  II  READ_DATAFI!J!\n") ; 

) 

also 

print!  ("CAIIOT  READ  II  VEHICLE  ATTRIBUTES,  IOT  EIOUGH  MEMORY \n”) ; 

) 

) 

also 

print!  ("CAIIOUT  OPEI  VEHICLE  FILE  FOR  RSADHGNn") ; 

higheat.obj.id  •  objact ->objaet_ld; 
fcloaa  vptr.to.dataf 11a) ; 

) 


/♦•♦♦ . . . . . / 

/•  DATE;  08/02/90  •/ 
/♦  VKRSIOI:  0,0  ♦/ 
/•  TITLE;  tand.fupdata  ♦/ 
/«  MODULE.IUXBER;  2.17  •/ 
/•  DKSCR1PT10I:  Thit  function  it  utad  to  aand  poaition  updatea  to  a  file  */ 
/•  for  lttar  tccatt  by  tha  generic  diaplay  */ 
/♦  ALGORITHM:  open  a  fila  to  atora  the  information  ♦  / 
/*  attract  and  read  tha  required  data  into  tha  datafila  a/ 
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/•  cloae  th«  dstafila  one*  th«  raiding  la  conplate  a/ 

/•  PASSED  VARIABLES :  object. lafo  a/ 

/*  RETVRIS:  BOD*  a/ 

/*  GLOBAL  VARIABLES  PASSED:  non*  a/ 

/•  GLOBAL  VARIABLES  CHAIGED:  BOB*  a/ 

/•  FILES  READ:  bobc  a/ 

/•  FILES  VRITTB1:  datafile  •/ 

/•  HARDWARE  IIPUT:  Boat  •/ 

/•  HARDWARE  OUTPUT:  bob*  */ 

/•  MODULES  CALLED:  bob*  */ 

/•  CALLIIO  MODULES:  raach.tuxnpoiat,  reachad.tsrget ,  reached.deatiaation,  •/ 
/•  reached.aenaor.rang*  •/ 

/•  ORDER  OF:  This  function  ia  of  ordar  0(1)  */ 

/•  AUTHOR:  Rob  Rixza  */ 

/*  HISTORY:  bobs  */ 

/eeeeeeeeeeeeaaeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeae . / 

void  send.fupdate  (object. info) 
struct  object .attributes  aobject.info; 

{ 

FILE  eptr.to.diaplay.f  ila; 


if  ( (ptr.to.diaplay.f  ile  »  fopan( "display . c“,  "a”))  !■  HULL) 

{ 

fprintf  (ptr_to.diaplay.fila,  "31  Id  Ilf  X.21f  X.21f  X.21f  Xlf  Xlf  Xlf  Xlf 
Xlf  Xlf  Xlf  Xlf  Xlf \n" ,  objact.info->obj«ct.id, 
object_info->current_tiBs,  object.info-blocstion.x.coord, 
ob jact.inf o->location . y.coord.  objact.inf o->locct ion . z. coord , 
objact.inf o->velocity . x.ralocity ,  object. inf o->»elocity . y.aelocity , 
ob jact.inf o->aelocity . z.selocity,  ob ja«t_info->oriantat ion .yaa, 
ob jact.inf o->oriont at  ion. pi tch,  object _lnfo->orlentat ion .roll , 
objsct.info->rotation.ya*_rata ,  obj«ct_info->rotation.pitch_rata, 
objact.inf o->rotation . roll.rata) ; 

f cloaa  (ptr.to_display.fila)  ; 

> 

alaa 

printf  ("CAWHOT  OPEI  DISPLAY  FILE  II  SERD.FUPDATEW)  ; 

) 


/***•****♦••**»• . . . ♦♦ . * . •*»•*•••♦ . . 

/*  DATE:  09/04/90  */ 
/•  VERSIOI:  0.0  •/ 
/a  TITLE:  sansor.cback  •/ 
/a  MODULE. HUMBER :  2.10  a/ 
/•  DESCRIPTIOI :  This  function  ia  usad  to  chack  shathar  a  aansor  contact  a/ 
/a  is  aada  prior  to  tka  aaxt  sehadulad  tnmpoint .  a/ 
/•  ALGORITHM:  aaa  discussion  in  Thasis  */ 
/•  •/ 
/*  •/ 
/•  •/ 
/a  PASSED  VARIABLES :  struct  arguaent _typa  arguaent  a/ 
/*  RETVRIS:  bobs  •/ 
/a  GLOBAL  VARIABLES  PASSED:  axtarn  struct  driver*  driver  */ 
/a  aztazB  struct  linked. llsta  naster.ob.list  a/ 
/a  GLOBAL  VARIABLES  CHAIGED:  (tone  a/ 
/a  FILES  READ:  Bona  a/ 
/•  FILES  VRITTEI :  ♦/ 
/a  HARDWARE  IIPUT:  nons  •/ 
/a  HARDWARE  OUTPUT:  nona  •/ 
/a  MODULES  CALLED:  nona  a/ 
/•  CALLIIG  MODULES:  alaost  all  tha  aaanta  call  thie  function  a/ 
/»  ORDER  OF:  0(1)  »/ 
/a  AUTHOR:  Rob  Rixza  a/ 


A-31 


/*  HISTORY  :  Bene  */ 

/..•....•.,ee,ee~e,e***e,,*,e**»..*te.ee**.»eeeee*eeeeoeeeeee*...**ee.*«.*.e/ 


told  eeneor.check  (event .orguaent) 

(tract  m&t.ugi  •event.ax^'iaent; 

{ 

int  naa.obja  ■  0,  nna.vehicler  ■  0,  i  ■  0,  J  ■  0,  eeneor .contact .found  -  0, 

valid. contactl  ■  0,  valid.cont act2  “  0,  coBtacti  ■  0,  contact]  *  0,  aenaing.r&nge 

doable  curr.tiae ,  eurr.x_ceerd_other.ob; ject ,  curr.y.coerd.other.ob, jact , - - 

tera_aader.rudicall,  tazB_BBdar_radicaia ,  a,  b,  cl,  c2,  event.tiae, 
dif i_ in.curr.x.coordj ,  diff .in.curr.y.eoorde ,  diff_iB.carr_x.vala, 
diff.in_carr_y.vala,  tiaa.at.Bait.Toataptl,  ti»a.at.naxt_rout»pt2, 
eeneor.contact.tiael ,  oenaor.eontact.tiae],  rangel ,  rang $2 ,  tiae.to.event; 

double  at iaa.pt r  ■  HULL; 

atract  location .type  aaaxt.roatapt  a  HILL; 
atract  objact.attribataa  aothar.objact  ■  BULL; 

(tract  objact.attribataa  aobjactl  «  BULL; 

(tract  objact.attributaa  *objact2  •  BULL; 

art  ora  (tract  liakad.liat  euaeter.obj.liet ; 
extern  atract  driver  *aiaulat ion. driver , 

num.vehiclaa  ■  ll.length  (aaetar.obj.liat) ; 

if  (event. arg^aent->objeetl->velocity .x.valocit y  !«  0.0  || 
event. argaaent->objectl->veloclty .y.valocity  !■  0.0  tl 
avant.arguaant->objactl->valocit'.r. velocity  !«  0.0) 

{ 

tiaa.at .next .routapt 1  ■  calc.t iaa.at.naxt.routept  (event. arguaant->objactl) ; 
event _t iaa  ■  tiaa.at .next.routeptl ; 

for  (i  ■  1;  i  <■  aua.vahiclee ;  i-ee) 

{ 

other.object  ■  (atract  object.attributeee)ll_pop(aaeter_obj_li(t) ; 

if  (event. arguaent->objectl->object_id  ■“  other. object->object. id) 
ll.ineert  (auxter.obj.liat ,  other.object)  ; 

else 

{ 

curr.tiae  ■  event.arguaent-iobjactl-ieorrent.tiae; 

curr.x.coord.other.object  ■  other. object->locat ion. x.coord  ♦ 

((curr.tiae  -  other_object->current_tiaa) 

•  other.object-ivelocity . x_ velocity) ; 
carr.y.coord.other .object  ■  other.object ->locat ioa . y.coord  * 

((curr.tiae  -  other.object-icurrer.t.tiae) 

•  other_object->velocity .y. velocity) ; 

diff_ia_curr_x_coorda  ■  event .arguaent-iobjec t 1 ->locat ion. x.coord  - 
curr.x.coord.other.object ; 

diff.in.curr.y.eoordi  ■  event. argttaent->objactl->loc»tion. y.coord  - 
curr. y.coord. other. object ; 

diff .in.carr.x.vela  ■  event. argaaent-iobjectl-bvelecity . (.velocity  - 
other. object->velocity . (.velocity ; 

diff .in.cnrr.y.vels  ■  event. arguaent->objecti->velocity .y.valocity  - 
other.ob ject-> velocity .y_ velocity ; 


/eeveeeeeeee  QUADRATIC  EQUATIOI  II  (t)  :  t  <■  (-b  +-  eqrt  (bb  -  4ac))/2a 
range!  »  (double)get.senaor. range  (event. erguaent->ob jact 1) ; 
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rang*2  “  (doiU<)|<t.««iuor.rug«  (othar.objact) ; 

■  «  (diff.ia_curr_z.aala  *  diff.ia_curr_z.vala)  * 
(diff.in.curx.y.Tala  *  diff.ia.curr.y.vala) ; 
b  •  (2.0  •  diff .lo.corr_x_coorda  •  diff_ia.curr.z_ vela)  + 

(2.0  *  diff .in.curr.y .coord*  a  diff_in.curr_y.vala) ; 
cl  “  (diff.is.eur.i.c«ord>  •  diff.in.curr.x.coorda)  ♦ 
(diff.ia.corr.y.coorda  •  dllf.b.nir.;.co«rdi)  - 
(raagtl  •  raagtl); 

c2  “  (diff.in.curr.x.coorda  •  diff_ia_eurr_x_coorda)  ♦ 
(dlff.li.«n.i.e«Mdi  *  diff.ia.curr.y.caarda)  - 
(rang*2  •  rang* 2) ; 

tara.uadar.radicall  ■  (b  a  b>  -  <4.0  a  •*  cl): 

if  (faba  (t*ra_und*r_radicall)  <  0.0401) 
tan.undar.radicall  «  0,0; 

te>m_undar_radical2  •>  (b  •  b)  -  (4.0  a  a*  c2) ; 

if  (faba  (i«rn_und*r.radical2)  <  0.0001) 
terB.undar  .  \dical2  *  0.0; 

if  (tan.under.radic  ’  >•  0.0  1 1  taru.undar. radical 2  >»  0.0) 

{ 

if  ((t  ij»*.*t_n*xi.rout*pt2  ■  calc_tia*_at_n*xt_rout*pt 
(othar_objact))  <*  curr.tiaa) 

t iaa.*t_n*xt_rontapt2  *  calc.tiaa_at_naitnaxt.rout  apt 

(otliav .  viij*ct)  j 

if  (tin?.,at.naxt.rout*pt2  <•  curr.tia"' 
t>B*_at_«axi_routapt2  ■  tiaa.at.naxt  aptl; 

if  (t*ra.undar_radicall  >»  0.0) 

1 

■enaor. content _riH*l  •  (-1  <  1  '  (tan.undar.radicall))  / 

(2.0  a  a)  *  curr.tl zia: 

if  (aansor.coatact.tiual  - 
It  aanaor.coatact.tiv- 
tt  aana^r.contact  ,«.» 

It  lina.of.*  i  ffh''  *n v 
Tttlid.conttctl  - 
> 

if  (tan_und*r_radical2  >■  0.0) 

{ 

/•  if  (t laa.at _n*xV_rout*pt2  **  otta*r_obj*ct->curr*nt._tia*) 
tiaa.at_n*xt_rout*pt2  •  t iaa.at.naxt.roataptl ;  a/ 

a*naor_co&tact_tlm*2  *  (-1  •  b  -  aqrt  (t*n_uad*r_radlcal2) )  / 
(2.0  a  a)  +  curr.tiaa; 

f  (aanaor. contact. ti**2  <  aaant.tia* 

tt  a*n*or_contact_tia*2  >  (curr.tiu*  ♦  0.0000001) 
tt  aanaor.contact.t i»*2  <■  t iua_at.naxt.root apt 2 
at  aanaor.contact.t iu* 2  <■  (tiaa.at.aazt.rautaptl  ♦  0.0000001) 
'l  lina.of .night  (avaat.argnaaat)  **  THUS) 

*alid_contact2  ■  TIDE; 

) 

if  (aalid.contactl  •*  TRUE  It  valid..coat  .  -  1  TRUE) 

{ 

objactl  ■  *v*bt.*rgua*nt->obj*ctl ; 
objact2  "  othar.objact ; 


rin* 

(cu  e-  .  -ju  ♦  0,0000001) 

tt.aaxt.routaptl 
.)  «  TRUE) 
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if  (aanaor.eontact.tinel  mm  sensor.conteut.tiiaeS) 

{ 

contact 1  «  VRUE; 
contact 2  «  TRUE; 

if  (rangel  «“  0.0  RR  range!  “  0.0) 

aenaiiig.rango  a  0; 

alee 

seneing.range  »  1 ; 

avant.tiao  «  aanaor.contact  tlaal; 

> 

if  (sensor.cont act _t Inal  >  aanaor .contact. tiaa2) 

{ 

contactl  m  FALSE; 
contact2  •  TRUE; 

evant.tiaa  *  aanaor .contact. tiao2; 

> 

if  (sanaor.contact.tiaal  <  aanaor. contact. tiael) 

{ 

contactl  “  true; 

contact2  ■»  FALSE; 

avant.tiao  ■  aanaor.contact. tlaal ; 

} 

) 

also  if  (valid. contactl  »■  TRUE  RR  valid. contact 2  «-  FALSE) 

{ 

contactl  m  TRUE; 
contact2  «  FALSE; 

avant.tiao  ■  aanaor.contact. tlaal ; 
objectl  m  event_arguaent->objectl ; 
object!  m  othar.objact ; 

> 

alsa  if  (valid.contactl  ■■  FALSE  RR  valid.contact2  »»  TRUE) 

{ 

contactl  ■  FALSE; 
contact2  m  TRUE; 

event.tiaa  *  aansor.contact.tiaa2; 
objactl  ■  event.argnaent-iobjectl ; 
objact2  ■  othar.objact; 

> 

) 

11. insert  (nastar.obj.list ,  othar.objact); 
valid.contactl  "  FALSE; 
valid.coatact2  “  FALSE; 

} 

} 

if  (contactl  ■■  TRUE  RR  contact2  “■  TRUE  RR  a  anting,  range  0  RR 

diffaronca.in.altitnda  (event. argraent)  »■  0.0) 

{ 

event. argnaent->ovent_tiae  ■  avant.tiao; 
evant.argnaent-iobjectl  •  objactl; 
event. argoaent->object2  *  object!; 

add. event .coords. to.ronte  (event. argnaant) ; 

if  ((tiae.ptr  «  (donble*)aalloc(sizeof(curr.tina))>  mm  IULL) 
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print?  ("CiHOT  MLLOC  TIHE.PTR  II  SEISOR.CHECIW’)  ; 
etias.ptr  *  evant_arguaa»t->esant.tias; 

scheduls.svent  (sinulat  ion.driver ,  tiao.ptr,  collision. distance.reached,  event .argument) 

> 

•Iso  if  (contact  1  »*  TRUE  1 1  contact2  “  TIDE) 

{ 

if  (contactl  “  HUE  it  contacts  “  TRUE) 

{ 

tiae.to.ovont  “  evest.aTgunent->objectl->cmrTsat_tiae  -  svsnt.tias; 
sdd.nev.routepoint  (evsnt.4rguaent->objectl ,  tiae.to.event) ; 
sdd.nee.rontepoint  (evsnt_argTKont*>objectl ,  tiao.to.svont); 

> 

also 

{ 

tiao.to.svont  ■  svsnt.tias  -  event_argunent->ebjeetl->current_tine; 
add.nes.routepoimt  (event_arguaent->objectl ,  tiao.to.svont); 

> 

event_arguni.jt->event_tiae  ■  svsnt.tias ; 
event_arguaent->objectl  ■  objsctl; 
event_arguaent->object2  ■  object2; 

if  ((tiao.ptr  “  (doublos)aalloc(sixeof (cazr.tias)))  ■■  IULL) 
printf  ("CiHOT  HiLLOC  T1RS.PTR  II  SEISOR.CBEClVn") ; 

etias.ptr  ■  event. srguaent->event  .tine ; 

if  (contact!  ■■  TRUE) 

schedule .event  (sinulat  ion.driver ,  tiao.ptr,  ontorod. sensor. range , 
event.arguaent) ; 

if  (contactl  ■■  TRUE  RR  event. aiguaent->objectl->object_tn>»  !*  EISSLE) 
schsduls.svsnt  (sinulat  ion.driver ,  tiao.ptr.  ando.ssnsor. Contact, 
event . arguaont ) ; 

else  if  (contactl  «»  TRUE  RR  event_argunsnt->objectl->object.tjfpe  «»  KISSLE) 
schsduls.svsnt  (sinulation.driver,  tiao.ptr,  ordnancs.roachsd. target , 
event  _  arguaont )  ; 

} 

else 

if  (ll.isoaptv  <svsnt.argnasnt->objoctl->routs.data)  !•  TRUE) 

{ 

nert.routept  ■  (struct  location_typee)ll_pop 
(event  _argu*ent->ob  jectl-lroute.dat  a) ; 

ll.inssrt  (event_»rguaent->ob jeetl-iroute.dat a  nert.routept), 

if  ((tiao.ptr  s  (doublse)aalloc(sixeof(curr_tiao))>  —  IULL) 
print?  ("CRIIOT  UUOC  II  CRSE  0x01  OF  SEISOR.CIEClNn"); 

etias.ptr  a  tiao.at.nsnt.rontaptl ; 

svent_arguaont->object2  ■  IULL; 
svsnt_axguasnt->svaat.tias  ■  svsnt.tias; 

schsduls.svsnt  <siamlatlca.driver,  tiao.ptr,  rsachsd.turnpoint , 
event  _  arguaont ) ; 

) 

} 

) 
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/*• . . 

/*  DATE :  09/11/90  */ 

/•  VERSIOE :  0.0  »/ 

/a  TITLE:  terminate. vehicle  a/ 

/ *  HnDnLE.BUMBER:  2.19  a/ 

l“-  DESCRIPTIOI :  This  function  is  ussd  to  toxainsto  in  objoct  and  any  •/ 

/•  associated  events  a/ 

/•  ALGORITHM:  -  sand  tho  terminator  id«st if ior ,  tha  vehicla.id  and  time  to  •/ 

/•  toxainsto  to  ths  display  driver  */ 

/ •  -  doloto  schodnlod  st ants  that  art  assoc iatsd  with  tha  a/ 

/•  identified  vehicla.id  a/ 

/*  PISSED  VARIABLES:  struct  object. attribetas*  object .info  a/ 

/a  RF.TURIS :  struct  1  inked. lista  delated. elects  a/ 

/a  global  VARIABLES  PASSED:  eimulat ion_driver ,  aastex.obj.list  a/ 

/a  GLOBAL  VARIABLES  CEAIOED:  aaatar.obj.liat  a/ 

/a  FILES  READ:  none  a/ 

/a  files  VRITTER:  display. e  a/ 

/a  BARDVARE  I1PUT:  none  4/ 

/ 4  BARDVARE  OUTPUT:  nonea  a/ 

/a  MODULES  CALLED:  delate.STont  a/ 

/a  CALLIBG  MODULES :  main  a/ 

/a  ORDER  OF:  This  function  is  of  order  0(a)  share  n  is  the  rumba r  of  objectsa/ 

/*  in  the  maeter.obj.liat  */ 

/a  AUTHOR:  Rob  Ricza  a/ 

/a  HISTORY:  none  a/ 

. . aaaaaaaaaaa/ 

int  delete.object  ();  /*  struct  object.attributea*  object. info,  inta  vehicle.id  •  / 

struct  linked. list  ataxainats. objects  (eeent. argument ) 
struct  event  ergs  eevant.ergument : 

{ 

extern  struct  linked.list  »nastar_obj_list , 
extern  struct  driver  asinulation.drivor ; 
struct  linked.list  sdeleted.eventa  “  BULL; 
struct  driver.data  aevent.data; 
struct  event.args  adeleted. event .argument ; 
struct  location_type  abogus.routept ; 

FILE  aptr.to.diaplay.file; 

if  ((ptr_to.dieplay.file  ■  fopen  ("display. c" ,  "a"))  !«  BULL) 

{ 

fprintf  (ptr.to.display.f ile ,  "33  Sd  llf\n",  event. argumont->objectl->objact. id . 
event_arguMent->objectl->current.tine  a  0.1); 
fclose  (ptr.to.display.f ile) ; 

) 

deleted.svents  ■  delete.event  (t insist ion. driver ,  event_arguaent->objectl->object.id) ; 
11. delate  (aaetex..obj_liet ,  delete.object,  B(event.argtaient->objectl->ebject.id))  ; 
chile  (ll.ieenpty  (deletad.evente)  !"  TRUE) 

{ 

event. date  a  11. pop  (dslstad.svsnts) ; 
deletad.avent. argument  •  event _data->fucc.arg™ente ; 

if  (deleted.sveat_argUB(nt->objact2  !■  BULL) 
if  (4eleted_event_ergu*ent->object2->object_id  ■■ 
event_exgu*ent->obJactl->objeet.id) 

bogus.routept  »  11. pop  (deletad.avent  .argument ->objectl->rc,ut  e  .data)  ; 

free  (bogus.routept); 

aensor.check  (deleted.eeent.srgunent) ; 

) 

} 

free  (event.arguaent) ; 
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return  deleted.events ; 


} 


. . . . */ 

/•  DiTE:  09/12/90  •  / 

/*  VERSIOI :  0.0  •/ 

/•  TITLE;  delete. vehicle  »/ 

/•  NODULE. HUMBER ;  2.19u  e/ 

/*  DESCRIPT10I ;  Thin  function  in  uei  by  ll.delete  to  delete  e  pointer  to  e/ 

/*  a  object  iron  the  naeter.obj.liet  e/ 

/*  ALGORITHM :  For  an  aany  iteaa  that  there  are  in  the  lint  •/ 

/*  ■  if  tha  vehicle. id  f roa  the  lint  nat  chan  the  referenced  id  •/ 

/*  then  delete  it  froa  the  lint  e/ 

/*  PISSED  VARIABLES:  struct  object. a* tribateae  object.info,  int  object. id  */ 
/•  RETURIS :  result  •/ 

/♦  GLOBAL  VARIABLES  PASSED:  none  */ 

/*  GLOBAL  VARIABLES  CHAIUED:  none  0/ 

/*  FILES  READ:  none  e/ 

/•  FILES  VRITTEE:  none  e/ 

/*  HARDWARE  IIPUT:  none  e/ 

/•  HARDWARE  OUTPUT:  none  e/ 

/»  NODULES  CALLED:  nona  e/ 

/*  CALLIIO  NODULES:  ll.delete  e/ 

/*  ORDER  OF:  This  function  is  of  order  0(1)  •/ 

/♦  AUTHOR:  Rob  Rizza  •/ 

/♦  HISTORY:  none  e/ 

/eeeeeeeeeeeeeaaeeteeeoeoeeeeeoeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeoeeeeeeeeeeeo/ 
int  4elete.ob,ect  (object.info,  obj.id) 
struct  object. attributes  •object.info; 
int  •obj.id; 

( 

int  result; 


if  (object.info-Robject.id  ••  eobj.id) 
result  -  LL.DEL.YES  I  LL.STOP; 

else 

result  ■  LL.DEL.IO ; 

return  result; 

} 


. . . . / 

/*  DATE:  09/30/90  •/ 
/«  VERSIOI:  0.0  •/ 
/•  TITLE:  npdate.object_current.tlae  •/ 
/•  NODULE. RUBBER :  2.20  •/ 
/•  DESCRIPTION:  Sluply  updates  the  currant  tine  of  the  object  •/ 
/•  ALGORITHM:  update  the  current  object  tine  to  the  current  event  tine  •/ 
/*  PASSED  VARIABLES :  event. ergs  eevebt.arguaent  •/ 
/*  RETURIS:  none  •/ 
/*  GLOBAL  VARIABLES  PASSED:  none  •/ 
/»  GLOBAL  VARIABLES  CHARGED:  none  •/ 
/*  FILES  READ:  none  •/ 
/•  FILES  VRITTEI :  none  •/ 
/«  HARDWARE  IIPUT:  none  •/ 
/*  HARDWARE  OUTPUT:  none  •/ 
/•  NODULES  CALLED:  none  •/ 
/*  CALLIIG  NODULES:  •/ 
/*  ORDER  OF:  Thin  function  is  of  order  0(1)  •/ 
/•  AUTHOR:  Rob  Rizza  •/ 
/*  HISTORY:  none  ./ 
. . . * . . . . . 
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void  updsta.objact.currant.tiaa  (event. arguaent) 
struct  avast. ergs  assent .arguaent ; 

( 

if  (event.arguaant  >objectl  !•  RULL) 

event_uguaent->ebjectl->current_tiav  -  a sent. ar guaant -> event _t  ine ; 

/*****••***••••,*••••••*••••••••••••••*••••***•*****•*••*****••••*•**♦••***•*/ 

/♦  DATE:  08/02/90  a/ 

/»  VERSIOi:  0.0  a/ 

/•  TITLE:  update.poe itios  */ 

/♦  HODULE.IUNBER:  3.21  a/ 

/*  DESCRIPTIOI :  This  function  la  usad  to  attract  tba  next  rout a  point  froa  */ 

/*  tha  routa  data  linked  Hat  a/ 

/a  ALGORITBH:  pep  tha  tan  roata  data  point  froa  tha  linked  list  */ 

/*  extract  and  read  tha  required  data  into  the  currant  location  */ 

/•  and  orientation  attributes  of  tha  vehicle  a/ 

/•  PASSED  VARIABLES :  object. inf o  a/ 

/a  RETURIS:  none  a/ 

/a  GLOBAL  VARIABLES  PASSED:  none  a/ 

/a  GLOBAL  VARIABLES  CHAROED :  none  a/ 

/a  PILES  READ,  none  a/ 

/»  FILES  WRITTEI :  none  a/ 

/a  HARDWARE  IRPUT:  none  a/ 

/a  HARDWIRE  OUTPUT:  none  a/ 

/•  NODULES  CALLED:  calc.curr.orientation  a/ 

/a  CALLIIG  NODULES :  raach.turnpoint ,  reached. target ,  reached. dast ination ,  a/ 

/a  reached. aenoor.rsngo  a/ 

/a  ORDER  OF:  This  function  is  of  order  CO)  a/ 

/•  AUTHOR:  Rob  Rizza  a/ 

/a  HISTORY:  none  a/ 

. . . . . . . . . 

void  update.position  (event. arguaent) 
struct  event.args  assent .argument ; 

{ 

struct  locstion.typa  anav.position.info  *  HULL; 

if  (ll.iaenpty  (event. arguaent->objectl->route_data)  TRUE) 

{ 

nae.poaition.info  »  (struct  location_t;pee)ll.pop 
(event. argument ->objectl->route_data) ; 

event. argument ->objectl->locat ion.  z.coord  ■  nee. position. info->x_coord; 
event. arguaant->objoctl->locat ion. y.coord  ■  nas. posit ion. inf o->y_ coord; 
event_arguaant->objoctl->locstion. z.coord  ■  aos_position.info->z. coord; 

f raa (nas. posit lou. info) ; 

calc.cnrr.oriontatiou  (ovent_*rguaent->objecU) ; 
celc.curr.valocitiaa  (avant.axgujaant->ob joctl) ; 
updato.object.carrant.tiao  (a vent. argument)  ; 
aand.f update  (event. argu»ant->ob jactl) ; 

) 

if  (ll.ieespty  (avant_arguaant->objactl->rosta.data)  It 
(evont_argumont->objectl->ebject_type  ■■  HISSLE)) 
torainata.objacta  (event. argument ) j 
) 
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Appendix  B.  TESTING  STRATEGIES,  RESULTS  and 

CODE 


B.I  Testing  Strategies 

A  bottom-up  strategy  was  used  to  test  the  simulation  software  written  for  this 
thesis.  Since  the  design  was  completed  prior  to  the  beginning  of  any  coding,  it  was 
reasonably  simple  to  identify  those  functions  that  did  not  require  any  outside  input 
other  than  those  variables  passed  as  arguments.  Thus,  since  these  functions  made 
no  function  calls  from  within  their  code,  they  made  up  the  lowest  level  of  functions 
which  were  tested.  Figure  B.I  illustrates  the  order  in  which  testing  took  place.  The 
lowest  step  functions  must  be  developed  and  tested  prior  to  moving  to  the  next 
higher  step. 

Each  function  tested  was  tested  using  two  strategies.  Pirst,  all  known  boundary 
values  were  tested,  as  well  as  any  value  which  was  determined  to  be  a  possible 
problem  (zero  is  a  good  example  of  a  problem  value).  Second,  to  the  extent  to  which 
it  could  be  determined,  all  branches  were  exercised  within  each  function. 

As  integration  took  place,  the  same  two  strategies  were  used  as  in  each  funct  ion 
test.  However,  it  should  be  noted  that  although  I  used,  for  the  most  part,  the 
same  boudary  or  problem  values  previously  found,  these  may  or  may  not  have  been 
boundary  or  problem  values  once  integration  took  place.  Also,  as  integration  took 
place,  determining  all  possible  paths  quickly  became  a  real  problem.  Thus,  it  is 
likely  that  only  a  sampling  of  paths  were  tested  during  the  integration  phase. 
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step  3 


step  1 


hit-miss 

operator.evaluation 


step  2 


damage-assessment 

evade 

on.collision.conrsc 

sensor-check 

update-position 


add-new-routepoint 

attack 

calc.curr.orientation 

calc-curr-velocities 

calc-time-at-next-routept 

calc-time-at-nextnext.routept 

dilTerence.in.altitude 

get-sensor.range 

nne.ofjsight 

on-target-list 

read-datafile 

send.fupdate 

tcrminate.objects 

update.object-current.time 


Figure  B.l.  Function  Development  and  Testing  Staircase 


B.2  Test  Results  and  Code 


The  objective  of  any  software  testing  is  to  find  errors  (15:191).  True  to  the 
stated  objective  many  errors  were  found  and  corrected.  However,  the  test,  results 
given  here  are  not  from  the  tests  where  errors  were  found.  The  results  given  are 
those  found  after  needed  corrections  were  made.  The  reason  for  inclusion  of  this 
information  here  is  to  first,  show  what  values  were  used  in  the  testing  process,  and 
second,  to  provide  repeatable  data  which  can  be  used  in  future  testing  or  validation. 

Please  note,  the  following  test  code  was  written  for  the  most,  part  in  ANSI 
C  to  run  using  Microsoft’s  Quick  C;  thus  if  used  on  another  system  some  slight 
modifications  may  be  needed. 

B.2.1  Test  1,  add-iicw-routcpoiyit  The  following  is  a  copy  of  the  code  used 
to  test  the  add  new  routepoint  function.  There  were  two  concerns  when  testing 
this  function.  First,  were  the  calculation  being  done  correctly  and,  second  were  the 
routepoints  being  properly  placed  into  the  object’s  route  data.  Initial  coordinates, 
velocity  vectors,  or  the  “in  x  seconds”  quantities  were  varied  during  each  test  run. 
No  problems  were  encountered. 


•include  "sue.  fane ,K" 

•include  "sin.otru ,h" 

•include  "11. h" 

•include  <atdio.h> 

void  ‘add.nes. routepoint  (struct  object _et tribute*  ‘object. info,  double  in.x.eecon-is) ; 

void  ntinO 
( 

etruct  object .attribute*  SIS ; 

•truct  local ion. type  enes.point; 

FILE  eptr.to_test.filo; 

FIS .locstion.z.coord  «  0; 

FIS . location .y.coord  •  0; 

FIS .location. r. coord  •  0; 

FIS .velocity .r .velocity  •  ISO; 

FIS . velocity  . y.velocity  ■  ISO; 

FIS . velocity ,r. velocity  ■  0; 

FIS . route.dsts  »  ll.nake  (LIFO); 
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srtd.nss.routspoint  ((FIS,  10); 

nev.  point  ■  ll.pop  (FIS .rout s.data) ; 
ptr.to.tast.flle  ■  fopenO'Ustl.res'W'); 

fprintf  (ptr.to.tsst.f ile,  "S  ■  Uf\t  J  •  llt\t  x  ■  Xlf\n",  n**.polnt->x_coord,  neu.point->y.coord. 
neu_point->x. coord) ; 

f  close  (ptr.to.tast.flle); 

> 

*oid  eadd.nsx.routepoint  (object.lnfo ,  in.x. seconds) 
struct  object .attributes  eebject.iafo ; 
double  in.x.sacondt; 

( 

struct  locstion.type  ensx.nsxt.pt  •  FULL; 

if  ((nsu.nsxt.pt  ■  (struct  location. type*)aulloc(tiisof (struct  location. tjp«)))«*IIUl.L) 
return  IULL; 

nsu.next.pt*>x_coord  ■  (object. inf»*>loeat ion. x.coord  ♦  (in. x. seconds  •  object. info*>»«locity velocity)) . 
nev_next.pt->y.coord  “  (object. info“>loestion.y.eoord  ♦  (in.x. seconds  ♦  object. info->velocity .y.vo'  oc ity>) ; 

new. next. pt->x. coord  ■  (object. info->location . x.coord  ♦  (in.x. seconds  •  object. info->»#locity.t. velocity)) ; 

11. insert  (object. info->route_data,  nas.next.pt) ; 

) 

/eeeeeeeeeeeeeeeeeeeeeeeeee  aaaple  output  seeeeeeeeeeeeeeeseeeeeeeeeeeeeeeeeeee/ 

i  e  1500.000000  y  a  1500.000000  t  •  0.000000 


D.2.2  Test  2,  calc-curr.orkntation  The  following  is  a  copy  of  the  code  used 
to  test  the  calculate  current  orientation  function.  Keeping  the  initial  point  coor¬ 
dinates  at  0,  0,  0,  the  next  point  was  varied  such  that  orientations  returned  were 
from  all  quadrants  including  angles  of  0,  90,  180,  and  270.  (see  the  sample  output 
following  the  test  code. 


(include  "sia.func.h" 

(include  "aiB.stru.h" 

(include  "11. h" 

(include<uetb.b> 

(include  <atdio.h> 

void  calc.curr.Arientatibn  (atruct  object-attributes  eobject.info) ; 

void  siainO 

( 

struct  object. attributes  FIS; 
struct  locstiin.type  pointl; 

FILE  eptr.to.test.f ile ; 
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FiS  .locat ion,*. coord  *  0; 

FiS. location. y.eoord  ■  0; 

FIS. location.!. coord  a  Oi 

FIS  .velocity .*. velocity  •  0; 

FiS .velocity .y.velocity  •  0; 

FIS. velocity, a. velocity  •  0; 

FiS.rnU.dit*  *  11. sake  (LIFO); 

point  1  .x. coord  •  0; 
pointl.y  .cooid  ■  100; 
point  1  x. coord  ■  100; 

11. insert  (FlS.rottto.4tto,  tpointi); 

calc.curr.orientetion  (*Fi$); 

ptr.to.teet.file  ■  fopen("teet2 .re*'1,  “o'1); 

(print!  (ptr.to_teat_.file,  "yav  ■  llf\t  pitch  •  Il#\t  roll  •  Ilf\n",  F1&. orientation. y»u,  FIS  oi  icntat  ion  p>u 
FiS .oriontttion. roll) ; 

fcloae(ptr_to_teat_f ile) ; 

) 

void  calc. curr. orientation  (object. info) 
struct  object. et tributes  oobjoct.info; 

{ 

double  delta.*,  delta.y,  dolts.*,  distance,  angle,  pitch; 
struct  location. typo  ‘next .route. point  » 

if  (ll.lseapty  (object. info->routo.data)  !•  1) 

( 

noxt.route.point  ■  (otruct  location.typoe)ll.pop  (object_info-iroute.dat*) ; 
delta.!  »  next. route. point*>*. coord  -  object. iafe-’Flocalion.x, coord; 
delta. 1  *  noxt.route.point ->y.«oord  -  object. inf o-ilocat ion. y. coord; 
delta. a  «  next.route.point->x.coord  *  object. inf®*>location.x.coori; 

angle  ■  aten2  (delte.y,  delta.x)  ♦  300  /  <2  *  3.14iM); 

if  (angle  <  0.0) 
angle  ■  3S0  ♦  angle; 

if  (angle  >*  0.0  il  angle  <«  90.0) 

object. info->orientit ion.yau  •  90.(1  -  angle; 

alae  if  (angle  >  90.0  tt  angle  <•  180.0) 

object. info'iorientetion.yae  •  3*0,0  -  (angle  -  90  0); 

elae  if  (angle  >  180.0  ii  angle  <•  370.0) 

object. info*>orientation.yae  •  370.0  -  (angle  ■  180.0); 

elae 

object. info* >orientet ion.yea  •  180  -  (angle  -  370.0); 

pitch  •  it  an  2  (delta.x,  (distance  •  aqrt  ((delta. x*delta.x)t(d»\te.yeiielta.y))))  •  3tio  /  (2  -  3.I41S9), 
object. info*>orieatation. pitch  •  pitch; 

object. info->erienteti«B. roll  •  object. iafo->orientnion  roll; 

il. insert  (object. infe->rottte_4ete,  next. roots. point) ; 

> 

olae 

( 

object, info~>oriantat ion. pitch  *  0,0; 
object. info->or ientat ion. roll  •  0.0; 

) 
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) 


/»»•«•••••••••••••••••••••••••••••  eeaple  eutpu 


yev  ■  44.999962 
yev  *  90.000000 
y dtf  >  136.000098 
ye w  •  190.000070 
ye*  -  326.000119 
ya»  *  299.999690 
ye*  •  314.999096 
M«  -  399.999924 


pitch  *  36.264419 
pitch  «  46.000036 
pitch  ■  36.264419 
pitch  •  46.000036 
pitch  -  36.264419 
pitch  •  46.000039 
pitch  «  36.264419 
pitch  •  46.000036 


tell  ■  0.000000 
tell  •  0.000000 
tell  •  0,000000 
tell  •  0.000000 
r«ll  ■  0.000000 
tell  ■  o;oooqoo 

roll  ■  0.000000 
tell  ■  0.000000 


/ 


B.2.8  Test  8,  calc. curt'. velocities  The  following  code  was  used  to  test  the 
calculate  current  velocities  function.  Like  calculate  current  orientation,  routopoinis 
were  varied  such  that  all  quadrants  were  represented.  See  the  sample  output. 


(include  "eia.func.h" 

•Include  "•ia.etru.h" 

•include  "11. h" 

•include  <aath.h> 

•include  iatdio.h> 

•old  celc.curr. velocities  (struct  object. attribute*  eobject.in^o) ; 

void  aeinO 

{ 

etruct  object. ettributee  FIS; 
struct  location. type  pointl; 

FILE  *ptr.to.te*t.fUe; 

ns. location.*. coord  •  0: 

Fis. location. y.coord  •  0; 

Ft S . location.!. coord  ■  0; 

FIS. velocity.!. velocity  •  ISO; 

FiS. velocity, y.velocity  •  ISO; 

FIS. velocity.!. velocity  •  0; 

Fts.route.dete  *  ll.aeke  (LIFO): 

pointl . x. coord  •  O; 
point  1 .y. coord  •  100; 
pointl  t. coord  “  10; 

U.ineert  (F16.reute.dete,  tpeintl); 

celc.curr.velocitie*  (9F1S); 

ptr.te.teet.file  ■  fepen("te*t3.re»",  "e"); 

(print*  (ptr.te.teet.file,  "x.vel  •  »lfVt  y.eel  -  tlf\t  x.eel  *  X»f\n",  FIS. velocity  x. velocity, 
Fis . velocity .y.velocity ,  FiS . velocity velocity) , 

(elwee(ptr.to.teet.file) ; 

) 
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r o id  cilc.cur.nlocitiM  (objsct.info) 
struct  objeet.attributes  ‘object .info; 

{ 

struct  locatlon.type  *n«xt .routs. point  •  IVLL; 

doubls  dslts.z,  delta./ ,  dslta.z,  elope.angle ,  horixoBtal.vel. vector , 
tiae. to. next.route. point ,  distanca.to.asxt .routs. point ; 

if  (ll.iaeapty  (objsct_info->routs.data)  !“  1) 

next .rout e.point  ■  (struct  location. typss)ll.pop  (object. iafo->reut*.data) ; 

horizontal. Tsl.ssctor  "  aqrt  ((object.info-ivslocity.x.vslocity  •  object. isfo-hvelocity .x.velocity)  ♦ 
(ob jact.inf o->»slocity ./.velocity  s  objoet.lnfo-hvelocity  ./.velocity)) ; 

dslta.x  ■  nsx t. rout s_point->x. coord  -  objsct.lnfo->locat ion. x. coord; 
delta./  ■  next.route.poiat-hy.ceord  -  ob j ect.inf o-ilocat ion. y. coord; 
delta.!  •  msxt _routs_point->x_coord  -  object. inf o->locat ion. x. coord; 

slops. angle  “  atan2  (delta. y ,  dslta.x); 

dintancs.to.nsxt.routs.point  “  sqrt  ((dslta.x  e  dslta.x)  ♦  (dalta.y  e  dslta.y)); 
tins.to.nsxt.routs.point  ■  diet ancs.to.nsxt. rout s.point  /  horizontal.asl. sector ; 

object. info->*slecity .x.velocity  ■  horizontal. eel. sect or  s  coa(alope. angle) ; 
object.info-hvelocity ./.velocity  ■  horizontal.vel.vector  *  sin(slope. angle) ; 
object. inf o->veloc it y . z.ralocity  a  dslta.z  /  timo.to.BOXt .route.poiht ; 

11. insert  (object. info->routs_data,  next .route. point) ; 

> 

else 

( 

object.info-hvelocity .x.velocity  *  0.0; 
object.info-hvelocity ./.velocity  «  0.0; 
object. info->velocity .z.velocity  a  0.0; 

) 

} 

/•••eeeeeeeeeeeeeeeeeaeeeeeeeeaeeeeee  sample  output  eeeeeeeeeeeoeseeeeeeeeeeeeeeeeeeeeeeeee/ 

r.vel  «  150.000000  y.vsl  *  ISO. 000000  Z.vsl  ■  16.000000 

x.vel  «  212.132034  y.vsl  »  0.000000  z.vsl  •  21 .213203 
x.vel  »  ISO. 000000  y.vsl  »  -150.000000  z.vsl  ■  15.000000 
i.vsl  ■  0.000000  y.vsl  -  -212.132034  x.vel  ■  21.213203 
r.vel  -  -150.000000  y.val  a  -150.000000  z.vsl  -  15.000000 
r.vel  »  -212.132034  y.vsl  •  0.000000  z.vsl  ■  21.213203 
x.vel  a  -150.000000  y.vsl  ■  150.000000  z.vsl  ■  15.000000 

x. vel  ■  0.000000  y.vsl  •  212.132034  z.vsl  »  21.213203 

y. vsl  »  0.000000  y.vsl  ■  212.132034  Z.vsl  ■  21.213203 


B.2.4  Test  4>  calc-time.aLnexLroutept  The  following  code  was  used  to  test 
the  calculate  time  at  next  routepoint  function.  Values  for  the  next  routepoint  loca¬ 
tions  varied  but  included  values  in  all  quadrants  as  well  as  the  next  routepoint  being 
the  same  as  the  current  routepoint  location. 


•include  “siB.ftmc.h" 
•  include  Msi*_»tra.h" 
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♦  include  "11  .h" 
ainclud*  <stdio.h> 
t inclod*  <nath.h> 

doubl*  ealc_tin*_at_n*zt_rout#p'-  (struct  object. attribute*  eobjset.inf o) ; 

void*  ns  in  () 

{ 

doubl*  tlna.at.neztpt ;  -  - 

struct  object. attributes  FIS,  1129; 

struct  locatioa.typ#  point. 1 ,  point. 2,  point .3 ; 

FILE  *ptr.to_t*at_fil#; 

F15 . location. z.coord  »  0; 

FIS .location. y. coord  ■  0; 

FIS .location. z.coord  “  0; 

FIS .velocity  .z.veloeity  ■  ISO; 

FIS .velocity  .y.velocity  «  loO; 

FIS . velocity .z. volocity  *  0; 

F15.curront.tin*  “  0; 

point. 1 .z.coord  *  -300; 
point. 1  y. coord  ■  300; 
point. 1 .2. coord  ■  30; 

point. 2. z.coord  ■  O; 
point_2.y_coord  *  -S; 
point. 2. z.coord  ■  0; 


FIS . rout*. data  «  ll.nak*  (LIFO); 

ll.ineert  (FIS .rout o.data,  tpoint_2); 
ll.ineert  (FIS .rout o.data,  tpoint.l); 

tino.at.noztpt  «  calc.tin*_at.n#zt.rout*pt(»F15) ; 

ptr.to.toat.fil*  «  f op#n("t«at4 .rot" ,"a") ; 

fprintf  (ptr.to.toat.fil#,  "tin#  at  n#zt  rontapoint  «  Xlf\n",  tin#.at_neztpt) ; 

fcloa«(ptr_to_t*at_f ila) ; 

) 

doubl*  eale_tin*.at.i»#zt.rout#pt  (obj#ct.info) 
struct  obj#ct_attribut#a  eobjoct.info; 

( 

doubl#  delta. z,  dalta.y,  dolta.z,  di#tanc*_tra*#l#d ,  tin*.at_n#zt.rout*pt ,  total.**l_*#ctor; 
struct  location.typ#  *nezt_rout#pt  *  IULL; 
int  #?«nt; 

tin#_at.n#zt.rout#pt  ■  obj#ct.lnfo->curr#nt.tin*; 
if  (ll.is«npty  (object. info->rout#_data)  !■  1) 

{ 

nozt.routspt  ■  (struct  location_typ##)ll.pop  (object. info->rout#.data) ; 
delta.*  -  obj#ct.info->location. z.coord  -  n«zt_rout#pt->z.coord; 
dalta.y  ■  object. info->location.y.coord  -  n#rt_rout#pt->y.coord; 
delta.*  ■  ob j«ct. inf o->loc*t ion. z.coord  -  n#zt_rout#pt->*..coord; 

11. insert  (obj*ct_info->rout#_data,  n#zt.rout#pt) ; 

distanc*_tra*#l#d  ■  sqrt  ((d#lta_z«d*lt*_z)  +  (d#lta.y#d#lta_y)  ♦  (d«lta.z*d*lta.z)) ; 
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total.vel.vector  »  sqrt  <(object_iafo->v-elecity .r.veloeity  •  ob  jeet _inf o->veloeit y.x. velocity)  + 
(object_info->veloeity.y_velocity  •  obJect_info->velocit7 .y.velocity)  + 
(object_info->Telc«ity.s_vel«ity  •  cbjeet_info->veleeity  .(.velocity))  j 

if  (total.Tel.vector  !“  0.0) 

time.at.next.routept  ■  object_info->car  .time  ♦  distance.’  raveled  /  total.vel.Tcci.oXi 
else 

time.at.next.routept  ■  objeet.lnfo-icurreat.tims ; 

> 

return  time.at.next.routept; 

> 

/••••••••••eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee  sample  output  eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee/ 

time  at  next  routepoint  ■  0.000000 
time  at  next  routepoint  ■  2.004994 
time  at  next  routepoint  ■  2.004994 
time  at  next  routepoint  ■  2.004994 
time  at  next  routepoint  “  2.004994 


B.2.5  Test  5,  calc-time.at-nextnexL routcpl  The  following  code  was  used  to 
test  the  calculate  time  at  nextnext  routepoint  function.  The  same  strategy  used  in 
testing  calculate  time  at  next  routepoint  was  used  to  test  this  function. 


(include  "sim.func.h" 

(include  "sim.atrtt.h” 

•include  "11. h” 

•include  <stdio.h> 

•include  <aath.h> 

double  celc.t ime.it. nextnext. routept  (struct  object. attributes  eobject.info) ; 

Toid*  mein  () 

{ 

double  tiae.et.nextpt; 

struct  object .attributes  FIS,  H29; 

struct  locetlon.type  point. 1,  point. 2,  point.3; 

FILE  eptr.to_test.file ; 

FIS .location. x.coord  »  0; 

FIS. locet ion. y .coord  «  0; 

FIS. location. x. coord  »  0; 

F15. velocity. x.velecity  ■  ISO; 

FIS. velocity .y.velocity  ■  ISO; 

FIS . velocity .z.velocity  *  0; 

FIS.  current  .time  ■  0; 

point.l . i. coord  ■  300; 
point. 1 .y. coord  ■  300; 
point.l .z.coord  ■  30; 

point_2 . x.coord  a  300; 
point_2.y.coord  ■  300; 
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point.S.z.coord  ■  30; 


FlS.roote.data  ■  ll.oake  (LIFO); 

11. insert  (FlS.route.data,  *point_2) ; 
ll.ineert  (F15.roata.data,  tpoint.l); 

tiae.at.naxtpt  ■  calc_tiae_at_nertnext.routept(»F16) ; 

ptr_to.taat.fila  -  f openC'testS.res" ,"a") j 

fprintf  (ptr.to.tast.file,  "time  at  naxt  routepolnt  ■  Xlf\n",  tiae.at.nextpt) ; 

feloaa(ptr.to_test_f ila) ; 

> 

doubla  calc.tiae.at.nextaext.roatept  (object.iafo) 
struct  object.attribntea  aobjact  info; 

{ 

doubla  dalta.z,  dalta.y,  dalta.z,  distance.traveled ,  tine. at. next. routept ,  total. vel. vector; 
struct  location.type  ‘next. .routept  ■  HILL,  •neitnext.routept  ■  lULL; 
int  avant ; 

tine.at.next .routept  ■  ob  jec  t_  inf  o->cur  rent  .tine; 

if  (ll.iaanpty  (object. inf o->routa_d»ta)  !■  l) 

{ 

next.routapt  »  (struct  locat ion_typee)ll_pop  (object. info->routa_data) ; 
dalta.x  ■  ob j act _inf o->locat ion. x_ coord  -  naxt. rontapt->i. coord; 
dalta.y  «  objact_info->location.y_coord  -  naxt .routept ->y_eooxd; 
dalta.x  «  object_info->location.z_coord  -  naxt_routapt->z. coord; 

distance. traveled  ■  sqrt  ((dalta.xadalta.x)  a  (dslta.yedelta.y)  a  (delta.xadalta.z)) ; 

total.val.vactor  ■  sqrt  ((objact_info->valocity . x.valocity  a  object. info->velocity .x.volocity)  ♦ 
(object. iafo-bvalocity .y.valocity  a  objact_info->valocity  y. velocity)  a 
(object. info->velocity .x.valocity  a  object. inf o->»alocity .x.valocity)); 

if  (total.val.vactor  !«  0.0) 

t ime.at .next .rootapt  «  object. info->current_tine  a  distance. traveled  /  total.val.vactor; 
elsa 

time.at. next .routept  ■  object. info->currant.t. iaa; 

} 

if  (ll.isempty  (object. info->routa_data)  !■  1) 

{ 

naxtnaxt.routapt  “  (struct  locat ion. types) ll.pop  (object. info->ronte.data) ; 
dalta.x  a  naxt.roatapt->x_coord  -  naxt na x t. root apt->x. coord; 
delta.y  *  naxt_routapt->y.coord  -  next next .routept ->y. coord; 
dalta.z  >  naxt .root apt->z_ coord  -  naxtnaxt.rootapt->x. coord; 

diat anca.tr avolod  ■  sqrt  ((dalta.xadalta.x)  ♦  (dalts.yadalta.y)  a  (delta. z*delt*_z)) ; 

total.val.vactor  ■  sqrt  ( (object _info->velocity, x.valocity  a  object_info->velocity .x.valocity)  + 
(object. info->valocity .y.volocity  •  object. info->valocity .y.valocity)  a 
( objoct. inf o->volocity .x.volocity  #  ob joct. inf o->valocity .x.valocity)) ; 

11. insert  (objact_info->routs.dsts,  nsxtnaxt.rontapt) ; 

11. insert  < ob jact. inf o->ronta_dats ,  nsxt.routspt); 

if  (total.val.vactor  !“  0.0) 

time.at.noxt.routepc  ■  t iso. at .next. rootapt  a  distance. traveled  /  total.val.vactor; 
else 
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tino.at.nert.routept  m  tiae.at.nezt.routapt j 

return  tine.at.next.rontept; 

} 

if  (next.xoutept  !■  BULL  U  nextaeit.routept  «•  BULL) 
11. insert  (object.info->route_dat»,  next.roatept ) ; 

retu-n  tine.et. next.roatept ; 

> 


staple  ontpi 


/ 


tine  at 
tine  at 

tine  at 
tine  at 
tine  at 
tine  rt 


next  roatepoint  ■  0.000000 
next  roatepoint  ■  <.009964 
next  routepoint  ■  4.009966 
next  routepoint  *  4.009966 
next  routepoint  ■  4.009968 
next  routepoint  ■  2.004994 


B.2.6  Test  6,  attack  The  following  code  was  used  to  test  the  attack  function. 
The  major  concerns  in  test  this  function  were, whether  the  missle  object  was  getting 
created  properly  (i.e.  a  type  30  message  was  passed  to  the  dislpay),  and  whether 
the  missle’s  routepoints  were  getting  properly  calculated  and  placed  into  the  missle's 
route  data. 


•include  "ain.func.h" 
•include  "sia.atru.h" 
•include  "11. h" 
•include  <atdio.h> 
•include  <aath.h> 


void  attack  (struct  eesnt.erga  •eeent.arguaent) ; 

void*  aain  () 

{ 

struct  object .at tributes  FIS; 

struct  location. tppe  point. 1 ,  point_2,  polat_3; 

struct  eeent.axge  ♦eTont.eigunent ; 

FIS . velocity .x.Telocity  •  10; 

FIS. telocit;. /.velocity  ■  10; 

FIS .eelocitj. z. velocity  ■  0; 

FIS . object. type  •  1; 

F15 . object.id  •  123; 

FIS .current. tiae  ■  0; 

Fir. location. r.coord  ■  0; 

FIS .location. y. coord  ■  O; 

FIS . location .z.coord  “  0; 
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point. 1 .z.coord  »  GOO; 
point.l .y.coord  ■  GOO; 
point. 1 .z.coord  *  100; 

FIS .root e.data  “  ll.make  (LIFO); 

11. insert  (F15.ronto.dtt4,  tpolat.l); 

event_argument~>object2  ■  iFIS; 
event. argu»ent->event_tlme  -  10; 

4tt4Ck(«*«Bt.4ZgSB4&t)  ; 

) 

void  attack  (event .argument) 

•truct  •••nt.»{»  event  .argument ; 

( 

/•  extern  atrnct  llaked.list  enaster.obj.liat ; 

«xt«rn  struct  dr  Ivor  eeimulation.driver ; 

•xtsrn  int  highest.obj.id;  */ 

struct  location.type  • tempi,  »tenp2,  emiaele.routeptl ,  eniselo.roatept2,  «miasle..routept3 ; 
struct  object. attribute*  eniasla; 
struct  event.args  *nev_event. argument ; 
struct  location.type  emiaslo.routept ; 

FILE  eptr.to.tent.file ; 
double  et iBS.pt r; 

if  ((missl*  ■  (struct  object. attrlbntese)nalloc(aizeof (struct  object. attributes)))  (*  IULL) 

{ 

Bissle->object.t ype  ■  3; 

/•  ■issle->object_id  ■  +*highest .obj.id;  •/ 

Bissle->current_tiMe  ■  event. argument-bevent.time; 

nissle->location.x_coord  ■  eveat_argumont->objsctl->location. z.coord; 

nis*le->location. y.coord  •  event _argument->objectl->locat ion. y_ coord; 

aissle->locat ion. z.coord  ■  event _argu*ent->obj«ctl->locat ion. z.coord; 

missle->velocity.x_velocity  ■  1000.0; 

nissle->velocity .y.velocity  «  0.0; 

aissle->velocity.z_velocity  ■  0.0; 

nissle->orientation.yae  *  0.0; 

■issle->orientation. pitch  ■  0.0; 
uissle->orientation.roll  «  0.0; 
aissle->rotation.yas_rate  ■  0.0; 

■issle->rotation.pitch.rate  ■  0.0; 

Bissle->rotation.roll_rate  «  0.0; 

Bissle->sensors  ■  IULL; 
aissle-> target. list  “  IULL; 
nisale->armaments  “  IULL; 
aiasle-bdefanoive.ayatema  ■  IULL; 

tempi  •  11. pop  (event.argument-Fobject2-Froute.dat  a) ; 

Bissle->ronte.data  ■  ll.aake  (LIFO); 

nissle.routept3  ■  (struct  location.typee)nalloc(sizeDf (struct  location.type)) ; 
aissle.routept3->x_coord  “  teapl->z_coord; 
missis. routept3->y.coord  ■  teapl->y.coord; 

Bisale.routept3*>s_coord  *  tempi ->z.coord; 

missis. routepi2  ■  (struct  location.typeOmallocCeizeof (struct  location.type)); 
missis. routept2->v_eoord  ■  event .argument ->objsct 2 ->locet ion. a .coord  ♦ 

( (event. argument ->eveat .time  -  event. argument ->object2->current_ time)  * 
evenl.argument->object2->velocity .x. velocity) ; 
aisole.routept2->y_coord  ■  event_argux»nt->object2->location. y.coord  ♦ 
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( -  *v*Bt.arg«a*nt->ebj*et3->ctirr«nt_tia*)  • 
***at_arg«m*Bt->*bj«ct2->**l*eity . y_T«loeity) ; 
aiasl*.,ront*pt2*>z_coord  ■  •»«nt_*rgu»«Bt->obJ*eta->locat ion. z.coora  ♦ 

(  («**nt„arguMnt->**«nt_tl a*  -  «»*nt_argoB*nt->objoct2->cnrr«nt_t  i»«)  * 
o'r«nt_»rgTjn»nt->obj«ct2->T*locity  .z. velocity) ; 

if  (fab*  (Bisal*.rout«pt2->x_cocrd  -  ni**l*.rcDt*pt3->x. coord)  <  0.001  at 
fab*  (aia*l*.rotit«pt2->y. coord  -  Bi**l*.rcat*pt3->y_coord)  <  0.001  tt 
fab*  (ala*l*.ront*pt2~>i_coord  -  ai*al*_rent*pt3->x_coord)  <  0.001) 

{ 

t**p3  a  ll.pop  (w*»t.M|B* »at->obj*ct2->roat*.dat*) ; 
aissl*.ront*pt3->i.coord  a  t*ap2->x. coord; 

Bi*sl*_rout«pt3->y.coord  ■  t*ap3->;.coord; 
aissl*.roBt*pt3->z_coord  "  t*ap2->z_coerd; 
ll_in*«rt  (niaal*->ront*.d*ta,  al*al«_roat*pt3) ; 
ll.insert  (ni**lo->ront*_data ,  ai**l«.root«pt3) ; 

11  .insert  (ev*nt_»rgcm*nt->object2->roote_d»t»,  t*ap3) ; 
ll.insert  («vent.argtaent->obj*ct3*>root*.dat*.  t*apl); 

} 

«ls« 

{ 

ll_in**rt  (event  .argument -icbject2-ironte.dat*,  taapl) ; 
ll.insert  (ai**le->ronte..d*ta,  ai*al«_ront*pt3) ; 
ll.insert  (nissle->rcnte_data ,  ni*sl*_rootept3) ; 

} 

nissle.routeptl  *  (struct  location_type*)aalloc(sizeof (struct  location.type) ) ; 
aissle.routeptl->x_coord  a  ai**lo->loc*tion.x_coord; 
aiasle. root opt l->y_coord  a  nis*l*->location  .  y.coord; 
aissle.routoptl-iz.coord  “  ai**lo->loc*tion.z. coord; 
ll.insert  (ai(*l*->ront*.dtta,  aissle.routeptl) ; 

if  ( (nee.event.xrguaent  ■  (struct  ***nt_argse)aalloc(sizeof (struct  event.args)) )  a*  IULL) 

printf  ("OHIO!  H1LL0C  lEV.EVEBT.iRQUMEIT  IB  ATTACK") ; 

nen_*vent.argunent->objcctl  ■  aissle; 

new_event_srgunent->obJ*et3  ■  event _*rguaent->ob Ject2 ; 

n*v_*v*nt_nrguB*nt->**ent_tin*  «  *v*nt_argu»*nt->*T»nt.t  i*e ; 

I*  ll.insert  (uBter.obj.list ,  Biesle) ;  */ 

ptr.to.test.fil*  ■  fopan  ("to*t6.r«»",  "a"); 

fprintf  (ptr.to.test.file,  "30  Xd  Xd\n",  ai*«lo->obj*ct_id,  ai*sle->object_type) ; 
ehile  (ll.is*Bpty(n*v_eTent_argiu»*nt->obj*ctl->route_data)  !■  1) 

/ 

nisei*. routept  »  ll.pop(ae*_*vent_arguBent->objectl->rout*_dkts) ; 
fprintf  (ptr.to.test.file,  "r  coord  ■  Xlf\t  y  coord  ■  Xlf\t  z  coord  a 
Xlf \b",  nisBle_routept->z. coord, 

Bissle_routopt->y_ coord,  aissl*. root*pt->z_coord) ; 

> 

fclos*  (ptr_to_t*»t_f  il*) ; 

/*  If  ((tias.ptr  ■  (donbl*»)B*lloc(*iz*of (doablo)))  IULL) 
printf  ("C11I0T  WLLOC  TIHE.PTR  II  ATTACK") ; 

•  t  iao.pt r  ■  avent_arguBsnt->ev*nt_tias; 

schodule.event  (siaulstion.drivsr ,  t ine.pt r,  ordnance. releseed,  aee.evont.argunent ) ;  »/ 

> 

•lx* 

printf  ("CtHOT  H1LL0C  HISSLE  IB  ATTACK") ; 

} 

/•••••*••••••••••••••••••••••••••••••  saapl*  ontpnt  •*••••••#•«••*••••••••**••••••••••*•/ 

30  O  3 

x  coord  s  0.000000  y  coord  "  0.000000  z  coord  ■  0.000000 
x  coord  ■  100.000000  y  coord  a  100.000000  z  coord  ■  0.000000 
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x  coord  *  SOO . OOOOOO  y  coord  *  600.000000  t  coord  ■  100.000000 
30  0  3 

x  coord  ■  0.000000  y  coord  ■  0.000000  s  coord  ■  0. OOOCOO 
x  coord  >  100.000000  y  coord  •  100.000000  s  coord  ■  0.000000 
x  coord  ■  600.000000  y  coord  “  600.000000  z  coord  »  100.000000 


B.S.7  Test  7,  difference-in.altitude  The  following  code  was  used  to  test  the 
difference  in  altitude  function.  Z  coordinate  values  above,  below  and,  equal  to  each 
other  were  tested. 


(include  "eia.func  h" 

(include  "eia.etru.h" 

(include  "11. h" 

(include  <stdio.h> 

(include  <aeth.h> 

double  diff erence.in.altitude  (struct  event. urge  *event .argument) ; 

void*  Bain  O 

( 

struct  object .attributes  FIS,  H29; 
struct  event.args  *a*ont .argument ; 
double  difference; 

FILE  eptr.to.tost.filo; 

F15 . location .z.coord  “  O; 

F15.current.tine  ■  10; 

H29. location. z.coord  •  6; 

629.current.tuie  *0; 

629 .  velocity  .^.velocity  ■  0; 

event _arguaent->objectl  »  (FIS; 
event_arguaent->objoct2  ■  (629; 

difference  •  difforenco_in.altitude(ovont.arg«ent) ; 

ptr.to. test. file  “  fopen("test7 . res" ,  "a"); 

fpriatf  (ptr.to_test.filo,  "difference  “  Xlf\n",  difference); 

fclose  (ptr.to_test.file) ; 

) 

double  difference.in.altitude  (event. arguaent) 
struct  event.args  *event. argument ; 

( 

double  difference,  cnrr.tiae; 

curr.tiae  “  event_argument->objectl->current.time; 

if  ( (difference  ■  fabs  (event_nrgement*>objectl->lceation. z.coord  - 
(event_arguaent->object2->locet ion. z.coord  ♦ 

((curr.tiae  -  event_arguaent->object2->current_tiae)  • 
event. arguaent->object2->velocity  .(..velocity))))  <“  5.0) 
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return  0.0; 
else 

return  difference ; 

> 

/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeseeeeeee  ••■pi*  output  ♦*•••*•♦••••««••*•*•*•••••••••••••••/ 

difference  •  0.000000 
difference  »  1000 .000000 
difftlMU  “  0.000000 


B.2.8  Test  8,  geLsensor.range  The  code  used  to  test  the  get.  sensor  range 
function  follows.  Sensor  range  values  within  the  object’s  sensor  list  varied  above  and 
below  the  default  value  as  well  as  equal  to  the  default  value. 


•include  "sin.func  .h" 

•include  "sis.stru.h" 

•include  "11. k" 

•include  <stdio.h> 

•include  <sath.h> 

•define  RISSLE  3 

int  get.sensor. range  (etrnct  object. attributes  ^object .info) ; 

eoide  nain  0 

{ 

struct  object.attributas  F15; 

struct  sensors  esensorl,  esensor2,  *sensor3; 

FILE  eptr.to.test.f  ile; 
int  range ; 

FIS. sensors  *  ll.aiake  (FIFO); 

sensorl->range  ■  0; 
sensor3->range  ■  0; 
sensor3->range  *  034; 

11. insert  (FIS. sensors,  sens or 1) ; 

11. insert  (FIS. sensors,  sensor!); 
ll.insert  (FIS. sensors,  sensor3); 

range  ■  get .sensor .range  (»F1S); 

ptr_to.test.file  "  fopen  ("tests. res",  "a"); 

fprintf  (ptr.to.test.file,  "range  *  Xd\n",  range); 

f close  (ptr.to.test.file) ; 

> 


int  get.senaor.range  (object. info) 
struct  object.attributas  eobject.info; 

{ 

int  i,  length,  range  °  633,  tesp.range  •  0;  /*  default  tensor  range,  approx  1/2  mile  ♦  / 
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■tract  ■•■•or*  •••..'or  ■  IULL ; 


if  (object. iafo->a*naora  !■  BULL) 

{ 

length  «  ll.lcngth  (obj«ct_info->a*Baora) ; 

for  (i  *  lj  i  <“  l«ngth;  i+O 

{ 

aontor  *  (struct  a*naora*)ll_pop  (object. info->a*a*ora) ; 
if  (Mniot->rug«  >  rugt) 
rang*  *  a*&aor->raag*; 

ll_ina«rt  ( object. iafo->a*aaora,  aanaor); 

} 

} 

•la* 

if  (object_info->object_typ*  **  HI8SLE) 
rang*  *  O; 

raturn  rang*; 

} 

/a********************************  aaaple  output  •*•••**»*••••*•»***•»••»»»••»»<■••*•«*•*•/ 

rang*  *  3000 
rang*  •  833 
rang*  *  834 


B.2.9  Test  9,  onJargct-list  The  following  code  was  used  to  test,  the  on  target 
list,  function.  The  M29  object  type  was  varied,  values  used  were  1,  2,  3,  4,  and  5. 
See  sample  output  for  results. 


tinclud*  "aia.func .h" 

•  includ*  ''■im.atru.h" 
i include  "11. h" 
tinclud*  <atdio.h> 
tinclud*  <aath.h> 

td«f in*  HISSLE  3 

iiit  on.target.liat  (atract  object.at iributes  *obj«ctl,  atract  object.attrlbutes  *object2>; 

void*  aain  () 

( 

■tract  object.attrlbutes  FIS,  H29; 
atruct  targ*ta  targ*tl; 
struct  targ«ta  targets; 
atruct  targets  t argot 3; 

FILE  *ptr.to.t«at_fil*; 
int  return.ealue; 

H29. object. type  »  E; 

FI 5. target. Hat  -  11 .male  (FIFO); 

targ«tl .  target. i;ype  ■  3; 
targ*t2  target. type  ■  2; 
target 3. target. type  *  1; 
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ll.insart  (FIS.targat.llat,  lttt|«tl)  ; 

H.inoart  (FIS.targat.liat,  ttargatj) ; 
ll.inaart  (FIS.targat.liat ,  ttargat?) ; 

raturn.valu*  ■  on.targat.liat  (*F1S,  kK39> ; 

ptr.to.tut.fll* •  fopoo  ("taatlO.raa",  V); 

fprintf  (ptr.to_taat.fll*,  "ratara  aalua  ■  Xd\n",  ratura.valua); 

feloa*  (ptr_to.taat.fila) ; 

} 


int  on.targat.llat  (otjoctl,  objactl) 

•truct  objact.attributaa  tobjactl; 

•truct  objact.attributaa  tobjactl; 

{ 

int  nua.targats,  i,  raturn.aalu*  •  0; 

(truct  targata  atargat; 

if  (obj*ctl->targ*t.liat  !■  BULL) 

( 

num. targat a  »  ll.langth  (objoct l->t*rgat .list ) ; 

for  (i  ■  1;  i  <■  nua.targata;  i++) 

{ 

targat  «  ll.pop  (objactl->targat.liat) ; 

if  ( targat ->targat_typa  ■■  obj*ct2->obj*ct.typa) 
raturn.talu*  ■  1; 

ll.lnaart  (obj«ctl->targ*t.llat,  targat); 

) 

) 

raturn  raturn.valua; 

) 

/•••***•••••*••*••••••••••••*••••••••  aaapl*  output  «*•**••*••♦********»•••*•*•*•••*•♦•»»/ 

raturn  valu*  ■  1 
raturn  taluo  “  1 
raturn  valu*  ■  1 
raturn  Tain*  •  O 
raturn  valu*  ■  0 


B.S.iO  Test  10,  sen<Lfupdate  The  following  code  was  used  to  test  the  send 
file  update  function. 


ticcluda  "aiu.func .h" 

•includa  "aia.atru.h" 
tinclada  "11, h" 
tinclad*  <atdio.h> 

»oid  aand.fupdat*  (otruct  objact.attributaa  aobjact.info) ; 
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void*  nil  O 

< 

etruet  object. attribute*  FIS; 

FIS . object. id  »  0; 

F15.cartnt.tin  ■  2; 

F15. location. x. coord  “  6; 

FIS . location .y. coord  ■  S; 

FIS, locat ion . *. coord  »  Sj 
FIS.valoeity .x.valocity  ■  10; 

FIS. velocity  .y. velocity  ■  10; 

FIS. velocity .x.valocity  «  10; 

FIS. orientation. yav  ■  6; 

F15. orientation. pitch  ■  6; 

FIS. orientation, roll  ■  6; 

FIS. rotation. yav.rat*  •  7; 

FlS.rotatlon.pitch.rat*  ■  7; 

FIS. rotation. roll. rat*  ■  7; 

aend.fupdat*  (ItFlS)  ; 

) 

void  aend.ftipdat*  (object. info) 
etruet  object .attribute*  eobject.info; 

{ 

FILE  eptr.to.diaplay.f lie; 

if  (<ptr.to_dieplay.file  ■  fopenC'dieplay.c",  "a")>  (»  IULL) 

{ 

fprintl  (ptr.to.diaplay.f ile ,  "31  Xd  Xlf  X.21f  X.31f  X-21f  Xlf  Xlf  Xlf  XU  XU  Xlf  Xlf  Xlf  XlAn" , 

object. info->obj*ct_id,  objeet.info-7current.tiaa,  object. inf o->loc»t ion. *. coord,  object. info->loc«l inn  y.covi  .1, 

object .info->loc»t ion . r. coord ,  object _info->**locity . *. velocity . 

ob j*ct.info>>v*loc it y.y. velocity ,  object.lnfo-bvelocity .(.velocity , 

object.info->orlent*tion.ya* ,  object. inf o->cri*nt»t ion, pitch, 

object.info-borientat ion. roll ,  obj*ct_info*>rotation.yae.r*te,  object.info-brotntion.pitch.rnto  . 
object. inf o->rotat ion. roll.rate); 

fclose  (ptr.to.diaplay.f lie) ; 

) 

else 

piintf  ("ClilOT  OPEi  DISPUY  FILE  I»  SEID.FVPDiTEW) ; 

) 


/tee* ***********************************  staple  output  ***»****»#••**•»***•»»**•**•»♦»»•«»•«*•♦/ 

31  0  2.000000  5.00  5.00  S.00  10.000000  10,000000  10.000000  6.000000  6.000000  6.000000  7.000000  7.000000  7.000000 


B.2.!i  Other  Level  One  Functions  The  following  level  one  function’s  test 
code  was  not  included  here  either  because  none  was  created  since  the  funct  ion  was 
extremely  simple  (i.e.  the  current  line  of  sight  function),  or  because  they  were  tested 
during  integration. 


•  terminate_objccts 

•  update.object.current.time 
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•  line_of_sight 

•  read-datafile 


The  following  second  and  third  level  functions  were  tested  during  integration. 

•  operator  .evaluation 

•  damage-assessment 

•  evade 

•  on.colision.coursc 

•  sensor.check 

•  update-position 

•  hit.miss 


The  following  scenario  datafile  and  simulation  output  can  bo  used  as  a  bench¬ 
mark  for  future  runs  and  verification  of  upper  level  function  operation.  Figure  t i .2 
depicts  the  two  dimensional  representation  of  the  scenario.  At  time  t  there  are  eight 
objects  in  the  simulation,  a  flight  of  three  approaching  from  the  southwest,  a  single 
ship  approaching  from  the  northwest  on  an  intersecting  path  with  the  flight  of  three, 
three  tanks  moving  in  a  northwestly  direction,  and  one  other  single  ship  moving 
north  northwest.  At  time  At  later  two  of  the  flight  of  three  has  been  destroyed  as 
well  as  the  single  ship  attacker.  Now  only  one  of  the  flight  of  three  remains  as  well 
as  the  three  tanks  and  the  other  single  ship.  3y  some  other  At  later,  the  remaining 
single  ship  has  turned  due  north  to  evade  the  other  aircraft  as  the  other  aircraft  flew 
by.  On  the  last  leg  of  the  single  ship’s  journey  the  single  ship  destroys  the  three 
tanks. 
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datafil* 


V 


1  1  6  0  100  100  5  -30000  0  10  160  ISO  0  0  0  0  S  (  1  900  100  1000  6  0  0  10  38000  0  4000  48000  33000  4000 
12000  32000  4000  -20000  0  10  1  1  2000  10120000 

1  2  6  0  100  100  S  -20080  -80  10  160  160  O  0  0  0  5  6  1  900  100  1000  6  80  -80  10  38080  -80  4000  48080  32080 
4000  11920  32080  4000  -20080  -80  10  1  1  2000  1  0  1  2  0  0  0  0 

1  3  6  0  100  100  6  -19900  -300  10  160  160  0  0  0  0  6  6  1  900  100  1000  6  80  80  10  37920  80  4000  47920  31920 
4000  12030  31920  4000  -19900  -300  10  1  1  2000  1  0  1  2  0  0  0  0 

2  4  9  0  100  100  6  -20000  32000  10  160  -160  0  0  0  0  6  6  2  1000  100  1000  2  12000  0  3500  -20000  32000  8.S 
1  1  1300  1000 

2  5  9  0  100  100  5  48000  0  6.6  126  126  0  O  0  0  6  6  1  900  100  1000  8  48000  0  10  20000  30000  6000  18000 
34000  SOOO  31000  34000  6000  38000  30000  6000  48000  06.611  3000  10140000 

4  6  6  0  100  100  &  32000  16000  2  -10  10  0  0  0  0  6  6  1  26  100  0  2  26000  24000  2  32000  16000  20000 

4  7  6  0  100  100  S  32070  16930  2  -14  10  0  0  0  0  6  6  1  26  100  0  2  26000  24000  2  32070  15930  2  0  0  0  0 

4  8  6  0  100  100  5  32140  16880  2  -10  10  0  0  0  0  8  6  1  25  100  0  2  26000  24000  2  32140  1S860  20000 


/.*•»••••••••••*»*•»••••••••«•»•«»**•«*«*  diaplay  t ila  •**•••••*•*•♦*♦**♦*.*•. 

32  i  fie 
32  2  nigl 
32  3  lainsil* 

32  4  tank 
32  5  truck 
30  1  1 
30  2  1 
30  3  1 
30  4  2 
30  5  2 
30  6  4 
30  7  4 

30  8  4 
SO 

31  8  0.000000  32140.00  16860.00  2.09  -9.328600  10.631707  0.000000  318.744273  0.000000 
0.000000  0.000030  0.000000  0.000000 

31  7  0.000000  32370.00  15930.00  2.00  -9.319192  10.837324  0.000000  318.778798  0.000000 
0.000000  O.OCOOOO  0.000000  0.000000 

31  6  0.000000  3200C  00  16000.00  2.00  -9.312661  10.643042  0.000000  318.B13964  0.000000 
0  000000  0.000000  0.000000  0.000000 

31  5  0.000000  48000.00  0.00  5.50  -65.653216  164.133011  27.325415  338.198496  8.787010 
0.000000  0.000000  0.000000  0.000000 

31  4  0.000000  -20000.00  32000.00  8.50  160.000000  -160.000000  16.368406  135.000038  4.411747 
0.000000  0.000000  0.000000  0.000000 

31  3  0.000000  -19900.00  -300.00  10.00  149.438208  150.659696  18.644730  44.786773  6.022943 
0.000009  0.000000  0.000000  0.000000 

31  2  O.OOCOOO  -20080.00  -80.00  10.00  149.625470  150.373597  18.656426  44.867080  5.026078 
0.000000  0.000000  0.000000  0.000000 

31  1  0.000000  -20000.00  O.CO  10.00  160.000000  160.000000  18.703125  44.999962  5.038594 
0.000000  0.000000  0.000000  0.000000 

31  1  100.000000  -5000.00  15000.00  1880.31  150.000000  150.000000  18.703125  44.999962 

30  9  3 

31  9  100.000000  -COOO.OO  16000. OC  1680.31  0.000000  1000.000000  -117.685938  359.999924 
-6.706388  0.000000  0.900000  0.000000  0.000000 

31  4  100.000000  -6000.00  17000.00  1645.14  160.000000  -150.000000  16.366406  135.000038 
4-411747  0.000000  0.000000  0.000000  0.000000 

31  4  100.153460  -4976.98  16976.98  1647.85  150.000000  -150.000000  16.366406  135.000038 
4.411747  0.000000  0,000000  0.000000  0.000000 

31  2  100,153460  -6094.49  14980.44  1878.61  149.625470  150.373597  18.656426  44.857080 
S.02G078  0.000000  0.000000  0.000000  0.009000 

30  10  3 

31  10  100.153460  -6094.49  14980.44  1878.51  58  765242  998.272418  -115.426690  3.368294 
-6.584329  0.000000  0.000000  0.000000  0.000000 

31  4  100.611513  -4908.27  16908.27  16DS.15  150.000000  -150.000000  16.366406  135.000038 
4.411747  0.000000  0.000000  0.000000  0.000000 
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31  9  100.611513  -SOOO.OO  16611.81  1608.41  0.000000  1000.000000  -117.68S937  359.999924 
-6.706388  0.000000  0.000000  0.000000  0.000000 

31  4  100.770236  -4884.47  18884.47  1657.76  160.000000  -160.000000  16.366406  136.000038 

4.411747  0.000000  0.000000  0.000000  0.000000 

31  3  100.813484  -4834.61  14678.46  1889.64  149.438308  160.669696  18.644730  44.785773 
5.022943  0.000000  0.000000  0.000000  0.000000 

30  11  3 

31  11  100.813484  -4834.81  14878.46  1889.84  -21.881903  999.784920  -116.692854  368.757644 

-6^.  593724  0.000000  0.000000  0.000000  0.000000 _  _ 

31  11  101.423163  -4847.83  16487.97  1619.17  -21.881903  999.784920  -116.692864  368.767544 
-6.693724  0.000000  0.000000  0.000000  0.000000 
31  9  102.000000-6000.00  17000.00  1846.14  707.108781  -707.108781  77.161979  136.000038 

4.411747  0.000000  0.000000  0.000000  0.000000 

31  10  102.163460  -4976.98  16976.98  1647.85  707.108781  -707.106781  77.161979  136.000038 

4.411747  0.000000  0.000000  0.000000  0.000000 

31  lO  102.260626  -4906.27  16908.27  1656.16  0.000000  0.000000  0.000000  135.000038  0.000000 
0.000000  0.000000  0.000000  0.000000 
33  10  102.360628 

31  1  102.333333  -4660.00  16350.00  1923.96  160.000000  160.000000  18.703125  44.939962  5.038594 
0.000000  0.000000  0.000000  0.000000 

31  4  102.333333  -4650.00  16650.00  1683.33  160.000000  -160.000000  16.366406  135,000038  4.411747 
0.000000  0.000000  0.000000  0.000000 

30  12  3 

31  12  102.333333  -4650.00  16650.00  1683.33  -0.000000  -1000.000000  16S.09S553  180.000076 
10.486521  0.000000  0.000000  0.000000  0.000000 

31  4  102.490372  -4626.44  16626.44  1685.90  160.000000  -150.000000  16.366406  135.000038 
4  411747  0.000000  0.000000  0.000000  0.000000 

30  13  3 

31  13  102.490372  -4626.44  16626.44  1685.90  -91.065945  -995.644864  181.696118  185.225013 
10.29808$  0.000000  0.000000  0. 000000  0.000000 

31  4  102.638496  -4619.23  16619.23  1686.69  ISO. 000000  -ISO. 000000  16.366406  135.000038 

4.411747  0.000000  0.000000  0.000000  0.000000 

31  9  102.538496  -4619.23  16619.23  1666.69  707.106761  -707.106781  77.151979  135.000038 
4  411747  0.000000  0.000000  0.000000  0.000000 

31  4  102.538496  -4619.23  16619.23  1686.69  160.000000  -ISO.OOOOOO  16.366406  135.000038 
4  411747  0.000000  0.000000  0.000000  0.000000 
33  9  102.638496 
33  4  102.638496 

31  11  102.813484  -4877.98  16877.98  1658.46  707.106701  -707.106781  77.151979  135.000038 

4.411747  0.000000  0.000000  0.000000  0.000000 

31  11  103.135893  -4650.00  16050.00  1683.33  0.000000  0.000000  0.000000  135.000038  0.000000 
0.000000  0.000000  0.000000  0.000000 
33  11  103.236893 

31  12  103.633333  -4650.00  16350.00  1923.96  707.106781  707.106781  88.167377  44.999962  5.038S94 
0.000000  0.000000  0.000000  0.000000 

31  13  103.790372  -4744.63  16331.85  1922.10  706.341229  708.867936  87.947235  44.8570B0  5.026078 
0.000000  0.000000  0.000000  0.000000 

31  12  103.963366  -4402.60  16597.50  1964.81  707.106781  707.106781  88.167377  44.999962  5.038594 
0.000000  0.000000  0.000000  0.000000 

31  1  103.983356  -4402.60  15597.50  1954.81  150.000000  160.000000  18.703126  44.999962  5.038594 
0.000000  0.0 OOv,'  0.000000  0.000000 
33  12  104.063366 
33  1  104.083366 

31  13  104.1403S5  -4497.94  16579.97  1952.69  706.341229  706.867936  87.947235  44.857080  5.026078 
0.000000  0.000000  0.000000  0.000000 

31  2  104.140395  -4497.94  15579.97  1962.89  149.626470  150.373697  16.656426  44.857080  5.026078 
0.000000  0.000000  0.000000  0.000000 
33  1  3  104.24039$ 

33  2  104.24039$ 

31  5  182.77866$  36000.00  30000.00  6000.00  -136.039406  110.431526  0.000009  308.659689 

0.000000  0.000000  0.000000  0.000000  0.000000 

31  3  214.001495  12080.00  31920.00  4000.00  212.132034  0.000000  0.000000  90.000000  0.000000 
0.000000  0.000000  0.000000  0.000000 

31  5  219.000095  31000.00  34000.00  6000.00  -176.776696  0.000000  0 .000000  269.999848  0.000000 
0.000000  0.000000  0. 000000  0.000000 
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31  5  359.363771  33664.64  34000.00  5000.00  -176.776695  0.000000  0.000000  369.99984B  0.000000 
0.000000  0.000000  0.000000  0.000000 

31  S  359.363771  33664.64  34000.00  6000.00  0.000000  176.776695  0.000000  0.000000  >..000000 
0.000000  0.000000  0.000000  0.000000 

31  5  319.363771  33664.64  44606.60  6000.00  -65.539065  -164.703163  0.000000  306.939353 

0.000000  0.000000  0.000000  0.000000  0.000000 

31  3  383.953676  47930.00  31930.00  4000.00  -63.563167  -303.365091  0.000000  197.436048 

0.000000  0.000000  0.000000  0.000000  0.000000 

31  5  367.934769  16000.00  34000:00  5000700  79.056943  -166.113663  0:000000  153.435003 
0 .000030  0.000000  0.000000  0.000000  0.000000 

31  S  413.333960  30000.00  30000.00  5000.00  130.617965  -139.333634  -31.495845  136.974974 
-6.933070  0.000000  0.000000  0.000000  0.000000 

31  5  463.696013  26086.30  23476.93  3915.00  130.617965  -139.333634  -21.495845  136.974974 
-6.933070  0.000000  0.000000  0.000000  0.000000 

30  14  3 

31  14  463.698013  36088.30  23476.93  3915.00  631.160567  -647.356641  -1304.332185  147.914793 
-52. 633533  0.000000  0.000000  0.000000  0.000000 

31  5  464.215957  26150.67  33410.00  3903.66  130.617965  -129.333634  -21.495645  136.974974 
-6.933070  0.000000  0.000000  0.000000  0.000000 

30  IS  3 

31  IS  464.215957  36150.67  33410.00  3903.66  631.071064  -647.337263  -1300.620964  147.922198 
-52.444675  0.000000  0.000000  0.000000  0.000000 

31  5  464.733661  36213.14  33343.07  3892.73  120.617965  -129.233534  -21.495845  136.974974 
-6.933070  0.000000  0.000000  0.000000  0.000000 

30  16  3 

31  16  464.733861  26213.14  33343.07  3692.73  630.980100  -647.384289  -1296.910042  147.928349 
-52.365539  0.000000  0.000000  0.000000  0.000000 

31  14  465.635183  27233.42  21666.20  1127.42  531.160567  -847.258641  -1304.332185  147.914793 
-52.523533  0.000000  0.000000  0.000000  0.000000 
31  14  465. 931065  27274.35  21584.96  1002.36  631.180567  -847.258641  -1304.332185  147.914793 
-52.523533  0.000000  0.000002  0.000000  0.000000 

31  14  466.027322  27325.48  21503.41  876.80  531.180587  -847.258841  -1304.332185  147.914793 
-52.523533  0.000000  0.000000  0.000000  0.000000 

31  15  466.257631  27234.94  21680.03  1248.42  631.071064  -647.327263  -1300.620964  147.922198 
-52.444675  0.000000  0.000000  0.000000  0.000000 

31  15  466.353131  27285.66  21599.11  1124.21  631.071064  -847.327283  -1300.620964  147.922198 
-52.444675  0.000000  0.000000  0.000000  0.000000 

31  15  466.449004  3T336.68  21517.68  999.52  631.071064  -847.327283  -1300.620964  147.922198 
-52.444675  0.000000  0.000000  0.000000  0  000000 
31  16  466.680435  27246.73  21693.67  1366.20  630.980100  -847.384289  -1296.910042  147.928349 
-52.365539  0.000000  0.000000  0.000000  O.OOGOOO 
31  14  466.698013  27681.74  20936.16  2.00  -656.604608  752.576695  0.000000  318.813964  0.000000 
0.000000  0.000000  0.000000  0.000000 

31  14  466.741048  27653.40  20967.64  2.00  -668.504608  762.576695  0.000000  318. 813964  0.000000 
0.000000  0.000000  0.000000  0.000000 

31  6  466.741048  27653.40  20967.64  2.00  -9.312661  10.643042  0.000000  318.813964  0.000000 
0.000000  0.000000  0.000000  0.000000 

33  14  466.841048 
33  6  466.841048 

31  16  466.775551  27297.23  21612.97  1244.64  630.980100  -847.364280  -1296.910042  147.928349 
-52.365539  0.000000  0.000000  0.000000  0.000000 

31  16  466.871038  27347.94  21532.08  1121.00  530.980100  -847.334269  -1296.910042  147.928349 
-52.365539  0.000000  0.000000  0.000000  0.000000 

31  15  457.215957  27743.88  20868.02  2.00  -856.988390  752.172385  0.000000  318.776798  0.000000 
0.000000  0.000000  0.000000  0.000000 

31  16  467.258992  27716.62  20900.39  2.00  -658.966390  752.172386  0.030000  318.778798  0.000000 
0.000000  0.000000  0.000000  0.000000 

31  7  467.256992  27716.52  20900.39  2.00  -9.319192  10.637324  0.000000  316.778798  0.000000 
0.000000  0.000000  0.000000  0.000000 
33  IS  467.358992 
33  7  4G7. 356992 

31  16  467.733861  27806.08  20800.91  2.00  -669.419504  761.77S177  0.000000  318.744273  0.000000 
0.000000  0.000000  0.000000  0.000000 

31  16  467.776896  27777.70  20833.27  2.00  -659.41960-1  761.776177  0.000000  316.744273  0.000000 
0.000000  0.000000  0.000000  0.000000 
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31  8  467 . 776396  27777.70  20833.27  2.00  -9.32S600  10.631707  0.000000  318.744273  0.000000 
0.000000  0.000000  0.000000  0.000000 
33  16  467.876896 
33  8  467.876896 

31  3  640.276717  37920.00  80.00  4000.00  -212.132034  0.000000  -22.368046  269.999848 
-6.019267  0.000000  0.000000  0.000000  0.000000 
31  6  645.360670  48000.00  0.00  10.00  0.000000  0.000000  0.000000  138.974974  0.000000 
0.000000  0.000000  0.000000  0.000000 

31  3  716.666188  80.00  80.00  10.00  07000000  oroooooo  0.000000  269.999848  0.000000 
0.000000  0.000000  0.000000  0.000000 
86  718.666188 
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Appendix  C.  SUPPORTING  CODE,  USERS  MANUAL  FOR 
THE  GENERIC  DRIVER  AND  LINKED  LIST  CODE 


C.l  Generic  Linked  List 

C.1.1  General  Description  This  program  can  be  used  to  create  instances  of  a 
PRIORITY,  LIFO,  or  FIFO  queues.  The  header  file  (ll.h)  contains  key  define  state¬ 
ments  and  the  prototypes  of  the  functions  available  to  manipulate  the  instantiated 
queues. 

C.l. 2  Reference  Descriptions  are  written  in  the  following  format: 

Function  name 


•  Summary 

•  Description 

•  Return  Value 

•  Example 

Below  the  name  of  the  function,  the  summary  shows  an  exact  syntax  model 
for  it  and  the  Description  outlines  its  actual  effects.  The  return  value  type  is 
given  and  is  often  useful  to  test  for  error  condition  if  one  is  given  before  the 
results  of  the  function  call  is  used.  Examples  are  referenced  in  the  included 
code,  where  needed  new  code  is  included  to  present  the  example. 
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ILclear 


•  Summary 
#include  “ll.h” 

struct  linkedJist*  ILclear  (Uist) 
struct  linkedJist*  Uist; 

•  Description 

The  ILclear  function  allows  the  user  to  empty  a  Uist  leaving  a  list  with  no 
elements. 

•  Return  Value 

The  return  value  is  a  pointer  to  the  list  which  was  emptied  by  using  this 
function  or  is  NULL  if  the  function  call  was  not  made  to  a  valid  list. 

•  Example 

See  function  end_sim  (3.3)  in  sim.driv.c. 
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ILdelete 


•  Summary 
^include  “ll.h" 


struct  linkedJist*  ILdelete  (lJist,  equalJree  ...); 
struct  linkedJist*  lJist; 

int  (*equaLfree)(); 

void*  cqualJrcc_argumcnts; 

•  Description 

The  ILdelete  function  allows  the  user  to  delete  one  or  more  occurrences  of  an 
item  from  lJist.  The  function  equalJree  will  be  called  from  within  ILdelete. 
EqualJree  will  be  passed  a  pointer  to  the  data  contained  within  an  element 
of  Llist.  The  equalJree.argunients  value  can  be  used  as  a  utility  pointer, 
however,  its  most  common  use  is  to  pass  ILdelete  changing  identifier  values 
which  equalJree  will  use  in  it’s  comparison  process  to  determine  if  an  item 
should  be  deleted.  Thus,  ILdelete  knowing  which  list  (lJist)  is  being  referenced 
will  match,  using  the  function  equalJree,  the  data  in  the  list  with  the  data 
passed  as  equal Jree.arguments.  Items  matched  will  be  removed  from  the  list. 
It  is  equal  Jrees  job  to: 

1.  Deallocate  the  memory  used  to  store  ‘data',  if  desired. 

2.  Let  ILdelete  know  whether  to; 
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-  delete  the  node  and  stop  searching  for  items  to  delete. 

-  delete  the  node  and  continue  looking  for  another  item  to  delete. 

-  not  delete  and  stop. 

-  not  delete  but  continue  searching. 

The  choices  are  given  as  the  return  value  of  equal-free  and  are  the  consequence 
of  a  bitwise  ‘or’  of  the  following  defines  from  11. h: 

-  LL.STOP  0x1000 

-  LL.CONTINUE  0x0000 

-  LL.DEL-YES  0x0001 

-  LL.DEL_NO  0x0000 

•  Return  Value 

The  ILdelete  function  returns  a  pointer  to  a  FIFO  list  containing  the  deleted 
data.  If  no  data  is  deleted  or  if  the  function  call  was  not.  made  to  a  valid  list 
NULL  is  returned. 

•  Example 


•  includa  <atring.b> 

* include  <*tdio.h> 

•  inclnda  “U.k” 

1st  aqual.fr**  (char*  data.to.mateh) ; 

char  um  [SO]  [80]  ; 

uinO 

{ 

struct  linkad.liat  *P() , 

•tract  linkad.list  •data.liat; 
int(acoaparaX)  ; 

FILE*  aoarca ; 
int  i  ■  0; 
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void*  output ; 
char*  nuo.pt r ; 
coapar*  ■  at reap: 

PQ  -  U.aak*  (P1I0KITY,  compare); 
data_li*t  ■  ll.nake  (FIFO); 

•ourc*  ■  fopen  ("uaaefile .c ’ » ,  "r"); 

thlla  ((MM.ptr  •  f|«ti(aui[i1,  SO,  source))  !*  HILL) 

{ 

ll.insert  (PQ,  neae.ptr); 
i** 

) 

fclos*  (source); 
ll.delete  (pq,  equal. fr««) ; 
printl  <"XdW\  11. length  (PQ) )  ; 
ohile  ((output  *  ll.pop(PQ)  !“  FULL) 
print!  (“XsVn1*,  output); 
print!  ("td\n>>,  ll.longth(PQ)) ; 
ohile  (iQl.iaeapty  (data. list))) 
print!  ("XsXn",  ll.pop  (data. list)) ; 

) 

int  equal. !re*  (data.!roa.list) 
char*  deta.fron.liat ; 

{ 

int  teap,  result; 
char*  cs  ■  ‘‘kethy”; 
int  n  *  S; 

temp  ■  etrncap  (ce,  date.froa.liet ,  u) ; 
i!  (tenp  •«  O) 

result  -  LL.DEL.YES  I  LL.COITIIUE; 

/*  result  -  LL.DEL.YES  I  LL.STOP;  •/ 

else 

result  •  LL.DEL.IO  I  LL.COiTIIUE; 
return  result; 

) 


This  program  reads  a  set  of  strings  from  the  file  ‘namefile.c’  inserting  each 
string  into  PQ  based  on  the  stremp  function.  After  the  file  has  been  read, 
items  matching  the  string  “kathy”  are  deleted.  Either  one  occurence  can  be 
deleted  or  all  occurrences  can  be  deleted  based  on  the  return  value  of  equal-free. 
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11-insert 


•  Summary 
#include  “ll.h" 

void*  11-insert  (Uist,  data) 

struct  linkedJist*  Uist; 


void*  data; 

•  Description 

The  11-insert  function  allows  the  user  to  insert  items  into  the  list.  How  an  item 
is  inserted  is  dependent  on  what  type  of  list  has  been  created,  either  a  LIFO, 
FIFO,  or  PRIORITY.  Respectively,  items  are  inserted  immediately  after  the 
head,  at  the  tail,  or  by  some  priority  mechanism.  The  sorting  methodology 
used  when  inserting  into  a  priority  queue  is  passed  into  the  structure  of  the 
queue  when  it  is  instantiated  (see  U_make). 

•  Return  Value 

The  11-insert  function  returns  a  pointer  to  the  data  which  has  been  inserted  or 
NULL  if  the  function  call  was  not  made  to  a  valid  list  or  not  enough  memory 
space  exists  to  accomodate  the  new  element  data. 

<»  Example 

See  function  car.arrives  (1.5)  in  hogwash.c. 
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ILisempty 

•  Summary 
^include  “11. h” 

int  ILisempty  (Uist) 

struct  linkedJist*  Uist; 

•  Description 

The  ILisempty  function  gives  the  user  the  ability  to  directly  determine  if  the 
list  has  any  elements. 

•  Return  Value 

The  llisempty  function  returns  true  if  the  list  is  empty  and  false  if  it  is  not 
empty.  If  the  function  call  was  not  made  to  a  valid  list  the  return  value  is 
NULL. 

•  Example 

See  function  end.wash  (1.7)  in  hogwash.c. 
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ILlength 


•  Summary 
^include  “11. h” 


int  ILlength  (Uist) 


struct  linkedJist*  Llist; 


•  Description 

The  llJength  functions  gives  the  user  the  ability  to  directly  determine  how 
many  items  are  in  the  list. 

•  Return  Value 

The  ILlength  function  returns  the  integer  value  of  the  number  of  elements  in 
the  list  or  NULL  if  the  function  call  is  not  to  a  valid  list. 

•  Example 


*includ«  <ttring.h> 

•  includ*  <»tdio.h> 

•includ*  "ll.h’' 

int  *qu*l_fr*«  (char*  d*t*_to_»*tch) ; 

char  nun*  [SO]  [SO]  ; 

««inO 

{ 

•tract  link«d_list  *PQ; 
int(*coBpnr*)(>  ; 

FILE*  •oarci; 
int  i  "  0; 
void*  outpnt; 
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char*  nuw.ptr; 
eoipiM  ■  ittctf; 

PQ  ■  ll.iUt  (PMOlin,  conpars); 
sourco  ■  fopsn  (‘ 'uMofilo  .e” ,  *'»**>: 
irhll*  ((na*o.ptr  o  fgots(naas[i] ,  #0,  uueO)  !■  HILL) 
{ 

ll.insort  <Pq,  asat.ptr); 
i+* 

) 

fcloas  (sourco) ; 
ll.doloto  (PQ ,  oqual.froo)  j 
printf  (''*d\n>\  ll.longth(PQ)) j 
»hil*  ((output  ■  ll.pop(PQ)  !*  flUU.) 
printi  («<XsW,  output); 
printf  ("Xd\n>\  U_longth(PQ)) ; 

) 

int  oqutl.fr**  (dtta.froa.list) 
char*  dats.iroa.list; 

{ 

int  t«p,  rosult; 
char*  c»  «  “kathy”; 
int  n  ■  5; 

tonp  ■  strnesp  (ca,  dtta.fros.list ,  n) ; 
if  <t«np  »■  0) 

rosult  «  LL.DEL.YE5  I  LL.C01TI1UE; 

/•  rosult  ■  LL.DEL.YES  I  LL.STOP;  •/ 

•ls« 

rosult  •>  LL.DEL.IQ  I  COITIIUE; 
roturn  rosult; 

> 
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ILmake 


•  Summary 
#include  “ll.h" 

struct  linkcdJist*  llanakc  (type, ...) 

int  type; 

unsigned  int  (*comparc)();  optional 
void*  utility.ptr;  optional 


•  Description 

The  ILinake  function  gives  the  user  the  ability  to  create  a  queue  by  choosing 
a  ‘type’  LIl'O,  FIFO,  ov  PRIORITY.  If  the  user  chooses  a  PRIORITY  queue 
then  they  must,  provide  a  pointer  to  a  function  which  will  be  used  by  the  list  to 
determine  where  an  item  gets  inserted.  The  optional  utility  pointer  argument 
is  provided  to  give  the  user  added  flexibility  in  using  the  functions  provided  by 
tnis  implementation.  An  example  of  a  possible  use  for  this  pointer  is  in  back 
referencing  which  may  be  required  when  using  an  intermediate  level  where  the 
user  supplied  function  is  not  given  directly  to  the  ILmake  function. 

•  Return  Value 

The  ILmake  function  returns  a  pointer  to  the  newly  created  queue  or  NULL  if 
there  is  not  enough  memory  to  create  the  queue. 

•  Example 
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See  function  main  (1.0)  in  hogwash.c. 
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lLpop 


•  Summary 
#include“ll^h,’ 

void*  ll.pop  (Uist) 

struct  linkedJist*  Uist; 

•  Description 

The  ll.pop  function  allows  the  user  to  take  items  off  the  top  of  the  queue.  Once 
an  item  is  popped  it  is  no  longer  in  the  queue. 

•  Return  Value 

The  ll.pop  function  returns  a  pointer  to  the  data  which  has  just  been  popped 
from  the  queue  or  NULL  if  there  are  no  items  to  be  popped  or  the  function 
call  was  not  to  a  valid  list. 

•  Example 

See  function  end.wash  (1.7)  in  hogwash.c. 
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C.l.S  The  Generic  Linked  List  Code  (11. h,  11. c) 


/,'«.**,„•••*•.••••*•*«**•*•••*•***•••••»•.»*»**»**•**•**•••**! 

/••eeeaeeeeeeeeeee  This  is  tk«  linked  Hat  header  file,  11  .h 

•define  FIFO  1 
•defies  LIFO  2 
•define  PRIORITY  3_ 

•define  LL.STOP  0*1000 
•dafina  LL.COITIIUS  0*0000 
•dafina  LL.DEL.YES  0*0001 
•dafina  LL.DEL.IO  0*0000 


/ 

/ 

■/ 


/* 


PHOTOTYPES 


»/ 


street  linkad.list  ell.dslete  O ;  /a  street  linkad.list  al.list,  int  (eequal.fr**) () , 

. . .  [equal.fres.arguasnts]  •/ 

void  *11. insert  ();  /•  street  linkad.list  al.list,  void  adsts  •/ 
int  ll.isaapty  O;  /a  street  linkad.list  al.list  */ 

street  linkad.list  ell.aake  ();  /*  int  type,  ...  [unsigned  int (‘compare) O  ,  void  »ut ility.ptr]  a/ 

to id  *ll_pop() ;  /a  street  linkad.list  al.list  a/ 

struct  linkad.list  all.elasr  ();  /•  street  linkad.list  al.list  a/ 

int  ll.langth  ();  /•  street  linkad.list  al.list  a/ 

/•a . . . . . aaaaaa/ 


/aaeaaeeeaeaei . . . .a...*...../ 

/a  DATE:  03/OS/90  a/ 

/a  VERSIOI :  0.0  a/ 

/a  TITLE:  Generic  linked  list.  a/ 

/a  FILEIAHE :  11.  c  a/ 

/a  COORDII1TOR:  Rob  tixxs  •/ 

/a  PROJECT:  EEIO  650,  sinter  90,  Bisbee  a/ 

/a  OPERiTIIQ  SYSTEM:  MS-DOS  •/ 

/a  LilOUROE:  Microsoft  Qeick-C  a/ 

/a  FILE  PROCESSIIQ:  coapila  and  link  with  fils  skieh  uses  a  linked  list  */ 

/a  COi'TEITS:  2.0  ll.aake  -  need  to  asks  an  instance  of  linked  list  a/ 

/•  2.1  11. pop  -  returns  top  itsa  froa  tbs  list  •/ 

/*  2.2  ll.clsar  -  aaptiss  ths  linked  list  a/ 

/a  2.3  ll.delate  -  delates  a  selected  iten(a)  froa  the  list  •/ 

/a  2.4  ll.isaapty  -  returns  tres  if  list  is  eapty,  alee  false  a/ 

/•  2.S  ll.langth  -  returns  ths  •  of  sleatnts  in  the  list  a/ 

/a  2.6  11. insert  -  inserts  slsaant  into  ths  list  by  calling  •/ 

/a  ll.piassrt,  ll.linssrt,  or  ll.f insert  a/ 

/a  2.6.1  ll.pinsart  -  inserts  element  baaed  on  a  priority  >/ 

/a  2.6.2  ll.linssrt  -  inserts  slsaant  onto  the  top  of  list  */ 

/a  2.6.3  U.fiasert  -  inserts  slsaant  onto  bottoa  of  list  a/ 

/a  FUICTIOI:  Allots  the  nsar  the  ability  to  crests  an  instanc*  of  a  LIFO,  a/ 

/a  FIFO,  or  PRIORITY  queue.  •  / 

. . a . . 

/a  Coda  begins  hare  •/ 

/« - ./ 

•include  "ll.h" 

/a  •include  <stdlib.h>  aaaa  coaaant  out  to  run  on  ten  eeeeeee/ 

•include  <stdio.h> 

•include  <aalloc.h> 


•define  TRUE  1 
•define  FALSE  0 

•dafina  LL.JUCIC  0*12345678  /a  used  to  check  for  Yalid  pointer  addressing  */ 
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/eoeeoeoesooeeseeeeeeseeeeeeeeee  STRUCTURES  •asseeoooeeaeaeoeoeoooososeoooooo/ 
struct  list.eleaent 
< 

void  odata; 

struct  list.elaasnt  enaxt; 

>; 


/• - •/ 


struct  liaked.list 

{ 

unsigned  long  magic; 
int  tjpall; 

struct  llat.eleaent  stall; 
int  (ecoapare)O;  /s  voids,  voids,  voids  s/ 
voids  utility.ptr; 
struct  list.elsaent  band; 

>; 


. . . 

/a  DiTE:  03/05/90  •/ 
/•  VERSIOI :  0.0  */ 
/•  NAME:  ll.uaks  •/ 
/a  MODULE  I UMBER;  2.0  •  / 
/*  DESCRIPTION:  Usar  can  inatantiata  a  linked  Hat  vitb  this  function  •/ 
/•  ALGORITHM:  Allocate  ataorj  for  linksd.list  atruetura  */ 
/•  initialize  the  structure  •/ 
/*  PISSED  VARIABLES:  type,  (sconpara)O ,  eutility.ptr  •/ 
/•  RETURIS :  struct  linkad.liete  tanp  •/ 
/♦  GLOBAL  VARIABLES  PASSED:  non*  •/ 
/*  GLOBAL  VARIABLES  CHARGED:  none  •/ 
/s  FILES  READ:  none  •/ 
/a  FILES  WRITTEN:  none  •/ 
/S  HARDWARE  INPUT :  non*  */ 
/*  HARDWARE  OUTPUT:  none  •/ 
/*  MODULES  CALLED:  none  •/ 
/•  CALLING  MODULES:  vhatever  executable  file  is  using  taa  data  atruetura  e/ 
/•  ORDER  OF:  This  function  ia  of  order  0(1)  •  / 
/«  AUTHOR:  Capt  Rob  Rizza  •/ 
/•  HISTORY:  none  •/ 
. . sssssssssssssssssssssssssssssssssssssssss . ossa . . 


struct  linkad.liste  ll.nakeCtype,  compare,  utility.ptr) 

int  typo; 

int  (scoapare) () ; 

void*  utility.ptr; 

< 

struct  linksd.liat  steap  ■  NULL; 

if ((teap> (struct  llnkad.llats)  aallocCsizaof  (struct  linked_list)))“NULL) 
return (taap) ; 

tenp->typ  allotype; 
t  eap->head . nsz t»NULL ; 
tsap->tailsRULL; 
tsap->aagicaLL_RAOIC ; 
t  eap->ut Hit  y_ptr«ut  ility.ptr ; 

if(typsa-PRIORITT) 

taap->coaparsscoapara; 

alas 

tonp->coaparo«NULL ; 
return(tenp) ; 

) 
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. . a..*.**.***...,***.,,**.***,.. . * . . 

/•  DATE:  03/OS/90  •/ 

/•  VERSIOH:  0.0  */ 

/•  HUE:  ll.pop  •/ 

/*  MODULE  HUMBER:  3.1  •/ 

/•  DESCRIPTION  latuil  tk*  top  itaa  froa  tko  link  ad  Hat  */ 

/*  ALGORITHM:  Robot*  tko  data  froa  tk*  top  cf  tk*  list  •/ 

/*  tars  point  >r  •/ 

/•  adjust  point or  to  bos  top  *loa*at  */ 

/*  doallocat*  sand  poiatsr  •/ 

/•  ratara  data  */ 

/•  PASSED  VARIABLES;  struct  llakod.llat*  l.llat  •/ 

/*  RETURBS:  oll.data  •/ 

/•  GLOBAL  VARIABLES  PASSED:  bobs  •/ 

/*  GLOBAL  VARIABLES  CEAHOED:  bob*  */ 

/*  FILES  READ:  bob*  •  / 

/•  FILES  WRITTEN  BOB*  •/ 

/*  BARDVARE  IIPUT:  bob*  */ 

/*  HARDWARE  OUTPUT :  Bon*  •/ 

/•  MODULES  CALLED:  bob*  */ 

/•  CALLIIO  MODULES:  shat*r«r  *x*cutsbl«  f ilo  it  using  tho  data  atructur*  •/ 

/•  ORDER  OF:  This  function  is  of  ord*r  0(1)  •/ 

/•  AUTHOR-  Capt  Rob  Rlzza  */ 

/•  HISTORY:  non*  •/ 

/a********************************************************************* . . 

void  sll.pop(l.list) 
struct  linkad.list  *l.liat i 
{ 

toid  sll.data  *  HULL; 

struct  list.alaaant  *t«ap  “  HULL; 


if  U.list->*agic  !-  U.HAGIC) 

{ 

printf  ("Magic  Busbar  tost  failsd  in  ll.pop,  chock  point*r\n") ; 
r*turn  HULL; 

> 

if  (l.list->h*ad.n*xt  !•  HULL) 
ll.data  *  l_list->h**d.n*xt->d»ta; 

•Is* 

{ 

printf  ("Cannot  pop  froa  o»pty  liat\n") ; 
rat urn  BULL; 

> 

tanp  ■  l_list->haad  .nsxt ; 

l_list->h*ad  ,n*xt  *  l.llat ->h*sd  .  n*xt->n*xt ; 

if  (l.list->boad.B*xt**IULL) 
l_Iist->tail«HULL; 

fr*«(t«ap); 

rat urn  ll.data; 

) 


. ♦*••*•.....•*.••/ 

/*  DATE:  O3/0S/9O  •/ 
/•  VERSIOH :  0.0  •/ 
/•  HARE:  ll.cloar  •/ 
/•  MODULE  HUMBER:  3.3  •/ 
/«  DESCRIPTION  Eaptios  tk*  liakad  list  •/ 
/*  ALGORITHM:  Vkil*  th*r*  ar*  *7.*a*nta  in  tk*  list  */ 
/•  pop  it«as  off  •/ 
/•  doallocat*  Bsaory  */ 
/*  raturn  pointar  to  th*  aapty  list  •  / 
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/•  PASSED  VARIABLES:  (tract  link«d_liat»  l.liat  ./ 

/•  RETURBS:  (tract  linkad.list*  l.liat  */ 

/•  GLOBAL  VARIABLES  PASSED:  Bona  */ 

/*  GLOBAL  VARIABLES  CBABOED:  BOM  •  / 

/•  FILES  READ:  bob#  »/ 

/•  FILES  W1ITTEI :  bob#  »/ 

/•  BARDVARE  IIPVT:  bob*  */ 

/•  IARDUARE  OUTPUT:  bob#  */ 

/•  NODULES  CALLED:  bob#  #/ 

/*  CALLUS  MODULES :  vkatovor  #x«cntabl#  f  11#  1#  using  th*  dot#  (tractor*  •/ 

/•  ORDER  OF:  This  inaction  is  of  order  0(b)  skor#  b  ■  Sitoas  la  th#  Hat  */ 

/*  AUTBOR:  Capt  Bob  Rixxa  ♦  / 

/•  IISTORY :  bobo  */ 

•tract  linkad.list  #U.«1obt  (l.liat) 

•tract  llak«d.llot  (l.liat; 

{ 

•tract  liat_#loaont  *aodo  ■  BULL,  #t#Bp  “  IULL; 


if  (l.liat->nagic  !■  LL.MAGIC) 

< 

printf  ("Magic  noabtr  t#at  fallad  in  ll.claar,  chack  point#r\n"); 
rttarn  BULL; 

> 

nod*  ■  il_list->h**d; 

shila  (nod#->n#xt  !»  BULL) 

( 

t#ap  ■  nod«->n#xt->n#rt ; 
fr*#  (nod«->n#xt~>data) ; 
fro#  (nod#->n#xt)  ; 
nod#->n#it  *  t#np; 

) 

r*tarn  l.liat; 

> 


A  . . / 

/•  DATE:  03/05/90  •  / 

/•  VER5I01 :  0.0  •  / 

/*  IAHE:  ll.dolot#  •  / 

/•  MODULE  BUHBER :  2.3  */ 

/•  DESCRIFTIOB:  D#l#t«a  a  sol#ct«d  itaa(a)  froa  th#  liat  •  / 

/»  ALOORITHH :  Vhil#  th*r#  ar#  #l#B#Bta  in  th#  liat  •  / 

/*  Batch  it«B  to  bo  d#l#t#d  •  / 

/•  d«l«t#  and  atop  a#arch  far  Batching  itaaa  or  •  / 

/•  dolato  and  continn*  looking  for  it#aa  to  d#l#t#  »/ 

/»  ratum  a  ptr  to  th#  laat  it#a  d#l*tad  •/ 

/•  PASSED  VARIABLES :  (tract  linkad.liat*  l.liat,  <*#4ual_f r##) (>  */ 

/*  RETURIS:  ptr_to.dat a  •  / 

/*  OLOBAL  VARIABLES  PASSED:  bob#  •/ 

/*  OLOBAL  VARIABLES  CBABOED:  BOB#  •/ 

/•  FILES  READ:  Bon#  »/ 

/•  FILES  VRITTEB :  bob#  •/ 

/•  BARDVARE  IBPUT:  bob#  */ 

/•  BARDVARE  OUTPUT:  non#  •/ 

/•  MODULES  CALLED:  bob#  •/ 

/•  CALLIEG  MODULES:  #hat###r  axaentabla  filo  la  aaing  th#  data  (tractor#  »/ 

/•  ORDER  OF:  This  Sanction  is  of  ord«r  0(n)  whor#  n  ■  Sitaaa  in  tha  list  •  / 

/*  AUTBOR:  Capt  Bob  Rizxa  •  / 

/•  BISTORT:  non#  •/ 

/••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••*••**•••*•/ 

•tract  linkad.list  *ll.d«l#t#(l_liat ,  •qnal.fron,  #qaal_fr##_argusents) 

•tract  linkad.list  #l.liat; 
int  (*aqual_f raa)  () ; 
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void  ooqual.f roo.arguaonts ; 

{ 

naaignod  let  raault; 
void  optr.to.data  «  BULL; 

•tract  liat.olonont  oaedo  •  BULL,  *t«ap  ■  HILL; 

■tract  linkod.liat  •dolotod.dota.liat  »  BULL; 

dol •  t o  d.dat  a.l iat  -  lljnaka  (FIFO)  ; 

if  (l.liat-Xaagie  I-  LL.MAOIC) 

< 

print f  ("Magic  aoabar  toot  foilod  in  ll.doloto,  chock  pointor\n") ; 
rotnm  IULL; 

> 

nodo  "  kl.liat ->hood ; 

ohilo  (nodo->Boxt  I"  BULL) 

{ 

raault  ■  (♦oquol.froo) (nodo->noit->doto ,  aqaal.fraa.argunanta) ; 

if(roanlt  k  LL.DEL.YES)  /*  if  roaalt  haa  a  1  is  tho  LSB  poaition  •/ 

(  /•  than  doloto  0/ 

tomp  »  nodo->novt; 

ll.inaort  (dolotod.data.liat ,  nodo->nozt->data) ; 

&odo->nort  “  nodo->noxt->nort ; 

if  (nodo->nozt  ■»  BULL) 
l.liat->tail  “  nodo; 


froo(toap) ; 

} 

ifCrooult  a  LL.STOP)  /•  if  roaalt  haa  i  1  it  tho  USB  poaition  •/ 
brook;  /o  thon  atop  •/ 

if  ('(roaalt  k  LL. DEL. YES))  /o  if  roaalt  haa  a  0  in  tho  MSB  •/ 
nodo  «  nodo->noit;  /o  poaition  thon  continuo  •/ 

) 

roturn  dolotod.data.liat ; 

> 

. . . . 

/•  DATE:  03/0S/90  »/ 

/*  VERSIOI :  0.0  */ 

/*  IAHE:  ll.iaooptf  */ 

/•  MODULE  BUHBER:  2.4  •/ 

/»  DESCIIPTIOB:  lotnma  tmo  if  tho  liat  ia  oaptj,  alao  rotnrn  falao  o/ 

/•  ALOORITBM:  If  thoro  ia  an  alonoat  in  tho  Hat  rotnrn  tno,  •/ 

/»  PASSED  VARIABLES :  o tract  linkod.liat*  l.liat  •/ 

/*  RETU11S:  tno  or  falao  */ 

/*  OLOBiL  VARIABLES  PASSED :  nono  ./ 

/•  GLOBAL  VARIABLES  CBABOED:  nono  •/ 

/•  FILES  READ:  nono  •/ 

/•  FILES  VRITTEI:  nono  o/ 

/»  HARDWARE  IIPUT:  nono  •/ 

/•  HARDWARE  OUTPUT:  nono  •/ 

/•  MODULES  CALLED:  nono  */ 

/*  CALLUS  MODULES:  ohatovor  oxocntablo  filo  ia  naing  tho  data  atrocturo  «/ 

/•  ORDER  OF:  Thia  function  ia  of  ardor  0(1)  o/ 

/•  AUTHOR:  Capt  Rob  Rizza  •/ 

/*  HISTORY:  nono  ./ 

. . * . . . . 

int  ll.iaonpty(l.liat) 

•tract  linkod.liat  ol.liat; 

( 
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if  (l_liat->n»gie  !■  LL.MAOIC) 

{ 

printf  ("Magic  nuabar  t«it  failed  la  ll.ioanptj ,  check  pointerVn") ; 
return  HULL; 

> 

if  (l.liswhsad.naxt  “  HULL) 
raturn  TRUE; 

return  FALSE: 

> 


/eeesseeeseeoeeeseeseeeeaeseeeeoaseeeeeeeeeeeeaeseeeeeeeeoeeeeeeeeeeeeeeeoaeeoe/ 

/•  DATE:  03/OS/90  a/ 

/•  VER5I0H:  0.0  */ 

/a  BAKE:  ll.langth  a/ 

/a  MODULE  HUMBER:  2.6  a/ 

/a  DESCRIPTION:  Returne  tha  nuabar  of  eleaoats  la  tha  Hat  •/ 

/a  ALGORITHM;  Whila  thara  ia  an  alanant  in  tha  list  •/ 

/a  incraaant  tha  counter  */ 

/•  return  countar  a/ 

/a  PASSED  VARIABLES:  struct  linkad.listt  1.11st  •  / 

/a  RETURIS:  1  (•  af  alaaents  in  tha  list)  a/ 

/a  GLOBAL  VARIABLES  PASSED:  sons  a/ 

/a  GLOBAL  VARIABLES  CBAIGED:  nona  a/ 

/a  FILES  READ:  nona  a/ 

/a  FILES  KRITTEB :  nona  a/ 

/a  HARDWARE  IBPUT:  nans  •/ 

/a  HARDWARE  OUTPUT:  nona  a/ 

/a  MODULES  CALLED:  nona  ♦/ 

/a  CALLUS  MODULES:  shstavax  executable  fila  la  using  tha  data  atructura  •/ 

/•  ORDER  OF:  This  function  is  of  ordar  0(n)  shara  A  *  titans  in  tha  list  •/ 

/a  AUTHOR:  Capt  Rob  Rixza  ♦/ 

/a  HISTORY:  nona  •/ 

/•aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa . a . . 

int  ll.langth  (l.liat) 
struct  linkad.list  al.list; 

{ 

int  i  •  0; 

struct  list. alanant  *noda  «  BULL; 


if  (l.llSWaaglC  !■  LL.HAGIC) 

{ 

printf  ("Magic  nunbar  tast  fsilad  in  ll.langth,  chock  pointer\r") ; 
raturn  HULL; 

) 

nods  ■  Al.list ->haad; 

•hila  <noda->naxt  !■  BULL) 

{ 

it*! 

noda  “  noda*>nazt; 

> 

raturn  i; 

> 


/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/ 

/a  DATE:  03/05/90  •/ 
/a  VERSIOB :  0.0  a/ 
/a  BAME:  ll.ins.i,  a/ 
/a  MODULE  IUMBER:  2.6  •/ 
/•  DESCRIPTIOB :  Insarts  an  alanant  into  tha  list  by  calling  ll.pinsert,  •/ 
/*  ll.linsart,  or  ll.finsart  “/ 
/a  ALGORITRM:  saitcb  to  salactad  typa  */ 
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/♦  PASSED  VARIABLES:  l.list,  data  •/ 
/•  RETURIS :  did  */ 
/•  OLOBAL  VARIABLES  PASSED:  bob*  •/ 
/•  GLOBAL  VARIABLES  CBAIOED :  bob*  •/ 
)*  FILES  READ:  bob*  «/ 
/•  FILES  VRITTEI;  bob*  •/ 
/•  HARDWARE  I I PUT:  bob*  •/ 
/♦  HARDWARE  OUTPUT:  bob*  */ 
/•  MODULES  CALLED:  ll.pina*rt  (2.6.1),  11.1  insert  (2.6.2),  or  •/ 
/*  ll.finsvrt  (2.6.3)  */ 
/•  CALLUS  MODULES:  vkatavar  *x«cataM*  (ill  la  using  th*  data  structure  •/ 
/*  ORDER  OF:  This  function  la  of  ordor  0(1)  •/ 
/»  AUTHOR :  Capt  Rob  Rina  */ 
/*  BISTORT :  bob*  «/ 


statlc  void  ll.linsort  ();  /•  struct  linked. list  *1.11*1,  struct  liat_*l*nont  *n*u.*l*Bent  «/ 

static  void  ll.plaa*rt  ();  /*  struct  link* A. Hit  *l_llst,  struct  liat.*l*a*nt  *a**.*l*nent  •/ 

static  void  ll.f  insert  ();  /*  struct  liakaa.litt  *l.list,  struct  li*t_«l*n*nt  *ne«.«l*Bent  •>/ 

void  •  ll_ins*rt(l_list,data) 
struct  link«d_li*t  el.liat ; 
void  *data; 

{ 

struct  list.*l*a*nt  *n*s_*l*Bent  “  BULL; 

if(l.list->aagie!-LL_HAGIC) 

( 

print!  ("Magic  nuabor  t*at  failed  in  11. insort,  ch*c*  pointerW) ; 
r«tuiii  ROLL; 

) 

if ((n**_*l«a*nt "(struct  list.eleaent  •)  aalloctsizaof (  struct  list.*l*B*nt)))>eBULL) 
r*turn(n«v.*l*a*nt)  ; 

B*n.*l*a*nt->dataBdata ; 

ssitch(l_liat->tjp*ll) 

{ 

cas*  PRIORITY:  ll.piasartO.list ,  n**.«l*n*nt) ; 
break; 

cas*  LIFO  :  ll.linsort  (l.list ,  B*s_«l*a*nt) ; 
break; 

cas*  FIFO  :  ll.fi&s*rt (l.list,  n*v.*l*a*nt) ; 

br*ak; 

dafault  :  return (BULL) ; 

> 

r*turn(n*u_*l*n*nt->data) ; 

) 


. . ••••**•«••• . */ 

/*  DATE:  O3/0S/90  */ 
t*  VERSIOB:  0.0  «/ 
/•  MANE:  ll.pineert  •/ 
/•  MODULE  BUMBER:  2.6.1  */ 
/•  DESCRIPTIOI:  Inserts  SB  *l*a«Bt  into  tbs  lint  based  on  a  user  supplied  »/ 
/•  coaparisoB  function  */ 
/♦  ALGORITHM :  lfbil*  th*r*  ar«  it*as  la  th*  list  •/ 
/*  coapir*  old  and  no*  Itoa  using  coapar*  function  •/ 
/*  if  ass  <*  old  continue  comparing  •/ 
/•  *la«  insert  into  list  */ 
/*  PASSED  VARIABLES:  struct  link*d.list*  l.list,  struct  li*t.*l*a*nt*  */ 
/•  B«*.«l*a*nt  */ 
/♦  RETURIS :  non*  */ 
/*  GLOBAL  VARIABLES  PASSED:  non*  */ 


C-19 


/•  GLOBAL  VARIABLES  CIABOED:  ROB*  */ 

/*  PILES  READ;  bob*  */ 

/*  FILES  VRITTEH :  bob*  «/ 

/*  BARDVARS  IIPUT:  bob*  ./ 

/*  IARDVARE  OUTPUT:  bob*  •/ 

/•  MODULES  CAUED;  bob*  */ 

/*  CALLUS  MODULES:  U.iastrt  (a. «)  */ 

_/•  ORDER  OF;  This  fuctioa  1*  of  ord«r  Q(i)  «h*r*  a  ■  llt*n  it  th*  list  •  / 

/*  AUTHOR:  Copt  Rob  Rita*  */ 

/*  HISTORY :  bob*  •/ 

static  void  U_pins*rt  (l.list ,  acs_*l*a*nt) 
struct  link*d_li*t*  1.11st j 
■tract  list.«l*a*nt*  B*s_*l«a*at; 

< 

strtct  list_*l«a*at  *B0d*  ■  FULL , *t«*p  ■  HULL; 


n*d«"Al.list->h*ad; 

■hil*(nod*->n*xt  !■  HULL  RA  (*(l.list->coapar*) ) (n**_*l*asnt->data,  nod*->n*xt->data,  l_list~>utility_ptr)  <«  0) 
nod*anod«~>B*xt ;  /•  loop  to  find  *h*r*  th*  lt«a  Bill  b*  ins*rt*d  »/ 

/•  b*s«d  on  tt«*r  d«fin«d  cosptr*  function  */ 

t«np>nod*->r.«xt ; 
nod«->n*xt*n**_*l«a*nt ; 

B«B.*l*B*Bt*>B*XtBt«ap; 


if  (n*a.*l«a*nt->n*xt  ■»  HULL)  /•  r«s«t  tail  ptt  if  n*«.«l*a*nt  is  th*  tail  */ 

l.list->tail  •  n**_«l«B*nt; 

> 

/•  DATE:  03/05/90  ./ 

/•  VERSIOI :  0.0  ./ 

/*  IAHE:  ll.lins*rt  •/ 

/•  MODULE  HUMBER :  3.6.2  ./ 

/*  DESCRIPTION:  In«*rts  nn  *l«a*nt  at  th*  top  of  th*  list  •/ 

/•  ALOORITHN:  In**rt  *l*B*ct  at  th*  top  of  th*  list  */ 

/*  adjust  point*™  •  / 

/•  PASSED  VARIABLES:  struct  linksd.list*  l.list,  struct  list_*l*n*nt»  •  / 

/•  B«s.«l*a*nt  •  / 

/*  RETURHS;  bob*  •  / 

/»  CLOBAL  VARIABLES  PASSED:  bod*  */ 

/•  GLOBAL  VARIABLES  CHAHOED:  non*  •/ 

/»  FILES  READ:  non*  »/ 

/*  FILES  URITTEH:  bob*  •/ 

/*  HARDWARE  IIPUT:  non*  */ 

/«  HARDWARE  OUTPUT:  bob*  •/ 

/•  RODULES  CALLED:  bob*  »/ 

/*  CALLIHQ  MODULES:  ll.inssrt  (2.6)  */ 

/*  ORDER  OF:  This  function  is  of  ordtr  0(1)  •/ 

/*  AUTHOR:  Capt  Rob  Rlssa  •/ 

/•  HISTORY:  non*  •  / 

. . . . . . */ 

static  void  ll.linstrt  (l.list,  n*s.*l*n*nt)  /•  ins«rts  at  th*  h*ad  of  list  */ 
struct  linksd.list  •l.list; 
struct  lisx.«l«a*nt  *B*s_*l*a«nt ; 

{ 

struct  list.«l«a*nt  *nod«  •  HULL,  *t*sp  ■  HULL; 


t*ap  ■  l_list->h**d.B«xt; 
l.li*t->h*ad.n»xt  ■  n*w_*l*n*nt ; 
n«*.*l*a«nt->n*xt  ■  t*ap; 

if  (n*v_*l«a*nt->n*xt  ■»  HULL) 
l_li*t->tail  •  n**.*l*a*nt ; 
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) 

. . *.*..***... . . 

/<■  DATE :  03/0S/90  */ 

/*  VERSIOI :  0.0  ♦/ 

/*  SAME:  11. f insert  •/ 

/♦  MODULE  HUMBER:  3.0.3  •/ 

/*  DESCRIPTION:  Intrti  on  alaaent  at  the  bottoa  of  the  Hat  •/ 

/*  ALOOR1TBM:  Insert  tlaint  at  the  bet  tea  of  tho  Hot  •/ 

/*  adjust  point  era  •/ 

/*  PASSED  VARIABLES :  struct  linked.list*  l.llat ,  struct  list.eleaent*  */ 

/•  aot.eleaent  •/ 

/•  RETURIS;  non*  ./ 

/*  GLOBAL  VARIABLES  PASSED:  bob#  «/ 

/*  GLOBAL  VARIABLES  CRAIOED :  bob*  «/ 

/•  FILES  READ:  bobo  */ 

/«  FILES  WRITTKI:  bob*  »/ 

/»  HARDWARE  IIPUT:  bobo  ./ 

/*  HARDWARE  OUTPUT:  bob*  */ 

/*  MODULES  CALLED:  bobo  •/ 

/*  CALLIIO  MODULES:  ll.inoert  (3.6)  •/ 

/*  ORDER  OF:  This  function  ia  of  order  0(1)  »/ 

/•  AUTHOR:  Copt  Rob  Rizzo  */ 

/«  HISTORY:  aono  ./ 

. . . 

Otatic  »o id  ll.f insert (1. list ,  noa.olaaont)  /*  inaorta  iteae  at  tho  toil  of  list  */ 
atruct  linked. Hat  ol.liot; 
atract  list.elenent  enew.eleuent ; 

< 

struct  liat.alonant  anode  »  BULL; 

if  (l_liat->toil  !-  HULL) 

( 

l.list->teil->next  ■  neu.eleaent; 
nev_elenent->nert  ■  HULL; 
l_liot->teil  ■  neo.oloaent; 

> 

alee 

{ 

l.list->h«ad .next  ■  Boa.eloaenti 
ne«_eleaeat->nert  ■  HULL; 
l_liat->tail  •  nea.elenent; 

> 

} 
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0.2  Generic  Simulation  Driver 


C.2.1  General  Description  This  piogram  can  be  used  to  create  an  instance 
of  a  simulation  driver.  The  header  file  (sim.driv.h)  contains  the  functions  which  can 
be  used  to  build  and  execute  an  event  driven  simulation^ 

C.2.2  Reference  Descriptions  are  written  in  the  following  format: 

Function  name 


•  Summary 

•  Description 

•  Return  Value 

•  Example 

Below  the  name  of  the  function,  the  summary  shows  an  exact  syntax  model 
for  it  and  the  Description  outlines  its  actual  effects.  The  return  value  type  is 
given  and  is  often  useful  to  test  for  error  condition  if  one  is  given  before  the 
results  of  the  function  call  is  used.  Examples  are  referenced  in  the  included 
code,  where  needed  new  code  is  included  to  present  the  example. 
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delete.event 


•  Summary 

^include  “sim.driv.h" 

struct  linkedJist*  delete_event  (driver,  eventid) 

struct  driver*  driver; 

nit  event  Jd; 

•  Description 

The  delete_event  function  gives  the  user  the  ability  to  remove  previously  sched¬ 
uled  events  from  the  Next  Event  Queue  (NEQ).  Using  the  event  jd,  returned 
to  the  user  when  using  “schedule-event” ,  delete_event  searches  for  a  matching 
eventJd  in  the  NEQ  and  deletes  it. 

•  Return  Value 

The  delete.evcnt  function  returns  a  pointer  lo  a  structure  containing  the  fol¬ 
lowing  information:  *time,  *event.,  *e  ven  t  .argu  tnents ,  and  an  eventJd.  (see 
“siin-driv.h”  for  structure) 

•  Example 

Replace  the  function  “end_wash”  in  hogwash.c  with  the  version  given  here. 
This  will  cause  all  rewashes  to  be  unscheduled  (ie.  deletes  all  rewash  events). 


void  «nd_»»sh  (trguasnt) 
struct  •rguatnt.list*  trguasut; 
t 

struct  dri»*r_d»t»«  d«l«t «d_d»t », 
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int  ooont.id; 


•tract  organont _ll»t*  tosp.orgoaont ; 
onoignod  int  J  ■  Oj 

print*  ("CM  Xd",  orgiu»ont->c*r_id) ; 

print*  (”  VtSR  » FIltSlfcD.  TXMX  STiNP*  XdW,  o»rgtuwnt->tiBo); 
ihilo  (joo  <  85000)  /*  tli<  to  rood  oroon  loop  ♦/ 

» 

if  (rondO  l  5  3)  /*  random  ••loction  of  roooohoo  ♦/ 

{ 

o»«nt_id  •  nchodulo.ooont  (argu»ont*>c»r»«»h,  argtwont->ti»o ,  rooooti,  argument); 
print*  ("REWASH.IP  io  Xd\n'\  oront.id); 
dolotod.data  *  doloto.ooent  (nrgunont->car»aah,  orant.id); 
print*  ("«font„id  dolotod  io  XdW,  dolotod_dita->o»ont.id) ; 

) 


•  1»4  if  Oll.iooaptp(lino))  /*  if  pnu  don’t  got  a  rovaah  got  noxt  start.wash  */ 

{  /•  from  tho  lino  if  thoro’o  aoa«one  in  it  */ 

toap.orguatnt  •  (ll.popUino)); 
argunont->car_id  •  tonp«.argtjaant->ear_id; 

nchodulo.ooont  (argu»ent->car»a»h,  argument ->tiao ,  start.wash.  argument); 

} 

> 
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end.sim 


•  Summary 
^include  “sim.driv.h” 

struct  driver*  end_sim  (driver) 

struct  driver*  driver; 

•  Description 

The  end_sim  function  gives  the  user  the  ability  to  «  1  op  the  simulation.  End.sim 
effectively  empties  the  Next  Event  Queue  (NE The  execute^im  function 
checks  for  an  empty  NEQ  and  terminates  execution  when  the  NEQ  is  empty 
(see  the  execute_siiri  function). 

•  Return  Value 

The  end.sim  functon  returns  a  pointer  to  the  simulation  driver. 

•  Example 

See  function  close.wash  (1.3)  in  hogwash.c. 
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executejsim 


Summary 

^include  “sim.driv.h,, 

struct  linkedJist*  executejsim  (driver) 

struct  driver*  driver; 

Description 

The  execute_sim  function  executes  thefunctions(events)  which  have  been  sched¬ 
uled  with  the  schedule_evert  function.  Execute_sim  will  continue  dispatching 
events  until  there  are  no  more  events  scheduled  in  the  Next  Event  Queue. 

Return  Value 

The  executejsim  function  returns  a  pointer  to  a  FIFO  queue  containing  the 
eventJd  and  time  of  event  for  each  executed  event. 

Example 

See  function  main  (t.O)  in  hogwash.c. 


make.driver 


•  Summary 
^include  “sim.driv.h” 

struct  driver*  make-driver  (sizeof.time,  compare.time) 

int  sizeof_time; 

int  (*compare_time)(); 

•  Description 

The  make_driver  function  allows  the  user  to  create  an  instance  of  the  simula¬ 
tion  driver.  The  user  can  then  use  the  functions  available  to  manipulate  the 
simulation  driver  in  creating  a  working  simulation.  The  compare  function  is 
supplied  by  the  user  to  allow  for  sorting  of  the  events. 

•  Return  Value 

The  make.driver  function  return  a  pointer  to  the  just  created  simulation  driver. 

•  Example 

See  function  main  (1.0)  in  hogwash.c. 
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print_stats 


•  Summary 
^include  “sinudriv.h” 

void  print-stats  (stats) 

struct  linked-list*  stats; 

•  Description 

The  print_stats  function  provides  the  user  with  a  viewable  output  from  t  ho 
returned  value  of  executejsim.  The  output  is  the  event Jd  and  time  of  event 
for  each  executed  event. 

•  Return  Value 

Printjstats  has  no  return  value. 

•  Example 

See  function  main  (1.0)  in  hogwash.c 
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schedule-event 


•  Summary 
#include  “sim_driv.h” 

int  schedule-event  (driver,  time,  event  June,  event_func_arguments) 
struct  driver*  driver; 

void*  time; 

void  (*event-func)(); 

void*  event _func_arguments; 

•  Description 

The  schedule-event  function  allows  the  user  to  schedule  events  by  passing  a 
pointer  to  the  event  function,  its  arguments,  and  the  time  of  the  event  with 
the  simulation  identifier  ‘driver’. 

•  Return  Value 

Schedule-event  returns  a  unique  event-id  for  each  newly  scheduled  event.  It 
returns  NULL  if  the  user  tries  to  schedule  an  event  at  a  time  which  has  already 
passed  or  there  is  not  enough  memory  space  to  schedule  the  event. 

•  Example 

See  function  main  (1.0)  in  hogwash.c. 
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C.2.3  The  Generic  simulation  Driver  Code  (sim.driv.h,  sim.driv.c) 


. . 

. . . . . 

/«  Thi*  is  tha  haadar  fill  far  •im.driv.c  */ 

. . a.......*#*.*.....***.....*..*...****.*...*.****.....*..**....****.***/ 


tdef ini  LL.DEL.YES  0x0001 
tdef  in#  LL.DEL.IO  0x0000 

struct  driver  aukt.dtiwr  (>;  /»i»t  siseof.tims,  lnt(aceapare_tl*e)0  •/ 

int  schadule.evint  O  ;  /•  struct  driver  adriisr,  raid*  time,  aoid(e*a«nt_func)  <> , . . .  [void  iivant.fune.argunients.l  »/ 
struct  linked.liat  eexecute.aimO;  /attract  driver  ‘driver  •/ 
void  print.stata  ();  /•  struct  liakad.lista  stats  »/ 
struct  driasr  aend.oim  ();  /a  struct  driaara  drlaar  */ 

struct  liukad.llst  adalata.aaaat  <);  /a  struct  driaara  dritar ,  1st  event. ident  */ 

struct  driasr.data  < 
void  »tia*; 
void  (afuBc)O; 
void  afunc.arguments j 
int  avant.id; 

}; 


. . »•••••••*••••*••• . .a....**............*../ 

. . * . . . aaaa.aaaa . . . ♦  *»*/ 

/•  DATE:  03/05/90  •/ 

/a  VERSIOI :  0.0  •/ 

/•  TITLE:  Oanaric  simulation  drivar  •/ 

/•  F1LKIAHE:  sis.driv.c  •/ 

/•  COORDINATOR :  Rob  Rizza  •/ 


/•  PROJECT:  EEIG  650.  aintar  90,  Biabaa  •/ 
/•  OPERATING  SYSTEM:  MS-DOS  •/ 
/*  LANGUAGE :  Microsoft  guick-C  •/ 
/«  FILE  PRQCESSIIG :  Lick  and  coapila  with  IX. c  and  axscutabla  fila  which  •/ 


/*  usaa  this  fila  •/ 

/a  C0ITE3TS:  3.0  aake.driaer  -  allows  uaar  tha  ability  to  a  aka  an  iustanca  a/ 
/«  of  sim_driv  •/ 

/*  3.1  schadula.sasnt  -  allosa  uaar  tha  ability  to  scbsduls  avants  •/ 

/»  3.1  axacuta.sia  -  azacutas  tha  achedulad  avants  */ 

/a  3.3  and.siu  -  terminates  tha  simulation  •/ 

/*  3.4  print.atats  -  prints  cut  tha  avant.id  and  tins  of  that  •/ 

/*  avant  for  all  axacutad  avants  a/ 

/•  FUNCTIOR:  Givas  a  uaar  ths  basic  functions  needed  to  run  an  avant  drivan  */ 

/•  aixulation  •/ 

. . . . . . . a . a . / 

/♦  Coda  begins  hara  •/ 

/• - •/ 


tincluda  <atdio.h> 
tincluda  <string.h> 
tincluda  <melloc,h> 
tincluda  "sin.dria.ir* 
tincluda  "11  .h" 

tincluda  "sim_atru.h"  /a  not  part  of  tha  original  gtnaric  sim.dria.c  coda  a/ 


. . . . a . . 

/»  Structural  usad  in  tia.dria  */ 

. . . . . . . . . . . . . 


struct  driaar  { 
int  sizeof.time; 
struct  driaar.data  acurr.aaant; 
struct  linkod.litt  •■EQ ; 
unsigned  long  event. id; 
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int  (*coapar*)();  /•  void*,  void*  •/ 

); 


. . . . we*****.*.*.*...,..,****,,*..,,** . . . •••/ 

/•  DATE;  03/06/90  */ 
/*  VERSIOI:  0.0  •/ 
/•  BADE;  Boko  driver  */ 
/•  MODULE  BUKBE A:  3.0  •/ 
/»  DESCRIPTION  Allow  th*  u*»r  to  erwt*  os  inotanc*  of  iia_driv  */ 
/*  ALGORITHM:  Allocate  aaaorp  for  (tract  drivor  •  / 
/•  uk«  on  in* tone*  of  priority  qnitt  •/ 
/♦  load  vtruct  drivvr  •/ 
/»  return  driv«r  */ 
/♦  PASSED  VARIABLES:  aizoof.tim*,  (ocomparo.timoK)  ♦/ 
/»  RETURIS:  drivvr  */ 
/•  GLOBAL  VARIABLES  USED:  bob*  »/ 
/*  GLOBAL  VARIABLES  CIAIOED:  BOB*  •/ 
/•  FILES  READ:  Bon*  «/ 
/•  FILES  VRITTEI :  non*  */ 
/*  HARDWARE  IBPUT:  bob*  */ 
/•  HARDWARE  OUTPUT:  bob*  */ 
/*  MODULES  CALLED:  ll.Btk*  (2.0)  */ 
/♦  CALLIIG  MODULES:  main  (1.0)  •/ 
/•  ORDER  OF:  Thi*  function  io  of  order  0(1)  */ 
/•  AUTHGR:  Copt  Rob  Rizxa  •  / 
/•  HISTORY:  non*  »/ 
. . * . •*••• . . . . 


int  ueu_compar*„tim*  ();  /«  struct  drivor.data*  n*v_data,  struct  drivor.data*  old.data,  struct  driver*  driver  •/ 

struct  driver  *aiak*..  driver  (aizeof.timo,  comparo.timo) 

int  uizeof.tiao; 

int  (*conparo..tim*)  () ; 

{ 

struct  drivor  *driv*r  •  1UIX; 
struct  linRsd.list  *BEq  ■  IULL; 

if  ((driv*r  •  (struct  driv*r*)B«lxoc(siz«of (struct  driv*r)))*oBULL) 
return  driver ; 

REQ  “  ll.aako  (PRIORITY,  nev.coapere.time,  drivor);  /*  creating  th*  B*zt  Event  Queue  (BEQ)  •/ 

driver->eurr_«v*nt  "  BULL; 
driver->IEQ  »  BEQ; 
driver->#v*nt.id  »  0; 
drivor->*izoof.time  “  siz*of_tine; 

<lrivo.r->co9f>ax*  ■  compare. time; 

return  drivor ; 

) 


/*«e*etv*eeo*eeeeeeeooee*eeo*oeeeeeeoeoeee*«eo*oeeoeoe*eeeeeeoee*eee****eeee**e/ 

/•  DATE:  03/06/90  •/ 
/*  VERSIOI:  0.0  •/ 
/•  BARE:  Compere  tiu  function  e/ 
/•  MODULE  BUMBER:  3.0.1  */ 
/•  DESCRIPTIOB:  Thin  is  the  function  that  is  passed  to  linked  list  */ 
/*  ALGORITHM:  Unpsck  and  pass  to  compare  */ 
/*  PASSED  VARIABLES :  onvv.data,  eold.data,  odrlvsr  •/ 
/•  RETURIS:  anaver  */ 
/•  GLOBAL  VARIABLES  USED:  non*  e/ 
/*  GLOBAL  VARIABLES  CBAIGED :  non*  </ 
/•  FILES  READ:  non*  */ 
/•  FILES  VRITTEI:  none  •/ 
/•  HARDWARE  IIPUT:  non*  •/ 
/•  HARDWARE  OUTPUT:  non*  */ 
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/»  MODULES  CALLED:  conpare.tiae  (1.1)  •/ 
/♦  CAU.IRQ  MODULES:  ll.pinsert  (B. 6.1)  •/ 
/»  ORDER  OF:  This  function  in  of  order  0(1)  */ 
/•  AUTHOR:  Copt  Rob  Rixzt  •/ 
/*  HISTORY :  non*  •/ 
/..*eeeo***e*******e*e*eo*******»****e*eee*e***ee***eeeee.eeeeeeeeee***eeeeee**/ 


int  new.coapore.tiae  (nev.data,  old.deta,  driver) 
struct  drivor.doto  enev.dat e; 
struct  drivor.doto  *016.6010: 
struct  driv*r  *driv*r; 

{ 

int  ensoor; 


answer  ■  driver- >co«pare  (nav_dntn-»t las ,  old_deta->t  ijee) ;  /•  tbs  tine  ports  ors  oxtroctsd  iron  •/ 
return  (int)ensver;  /*  new. dots  ond  old.doto,  passed  to  »/ 

>  /*  th*  user  defined  coapare  func  by 


/*  no*  of  a  ptr  to  driver  which  hoe  */ 

/•  o  ntr  to  the  coopers  function  •/ 

. . . . . see.*../ 

I*  DATE:  03/0S/90  */' 

/»  VERSU  S :  0.0  v/ 

/*  SAME:  Schedule  event  function  */ 

/•  MODULE  HUBER:  3.1  */ 

/•  DESCRIPTION  Allow  the  user  to  schedule  events  in  the  siaulation  •/ 


/•  ALGORITHM:  Allocate  nanory  for  struct  driver.dato  *( 
/»  check  to  seo  if  ovont  con  bo  scheduled  */ 
/•  loud  struct  driver.data  */ 
/*  Insert  driver.data  into  lEQ  »/ 
/•  return  event. id  •/ 
/*  PASSED  VARIABLES:  edriver,  etlas,  (eevsnt.funcX) ,  eevent.func.— puaents  */ 
/♦  RETURRS :  event. id  •/ 
/*  GLOBAL  VARIABLES  USED:  none  •/ 
/•  GLOBAL  VARIABLES  CHARGED:  non*  •/ 
/-  FILES  T.SAD:  none  •/ 
/♦  FILES  WRITTEH :  none  */ 
/*  HARDWARE  IIPUT:  none  */ 
/e  HARDWARE  OUTPUT:  none  •/ 
/*  MODULES  CALLED:  ll.ineert  •/ 
/■*  CALLIRG  MODULES:  noin  (1.0),  open.vosh  (1.4),  Stort..*o*h  (1.6),  */ 
/•  ond.vnsh  (1.7,  rovosh  (1.8)  */ 
/*  ORDER  OF:  This  function  is  of  order  0(1)  */ 
/*  AUTHOR:  Copt  Rob  Rizzo  */ 
/•  HISTORY:  non*  •/ 
. . *•*•*•*•••*•**•** . * . . . . . . 


int  schadule.ovent  (driver,  tine,  event. fnne,  event.func. arguments) 

struct  driver  edriver: 

void  *tiao; 

void  <aov»st.func)() ; 

void  eevont.func.arguaepta ; 

( 


int  i  «  0; 

struct  drivor.doto  enev.evait.dere  ■  HULL; 


•/ 


if  <(nev.ovont.dotn  »  (struct  dr ivar_data*)nalloc(»i*eof (struct  dri»er_dVc*)))««lULL) 
return  HULL; 


if  (dr It - r.— ent  !■  HULL) 

if  (driver->c©npere  (driver->cnrr_event->tise,  tiaa)  <  O)  /•  (vtiae  <  *(iiriv«r->curr  ,ovent->tine> )  */ 

{ 

print!  ("Cannot  schoduls  svsnt ,  not  ovont  tlae  is  already  hietory\n">; 
return  HULL; 

} 


now. event. dntn->func  ■  event.func; 

n«u. event. dnts->func_argunents  ■  event. func. orguaeutb ; 
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nev.**«nt.data*>*v*nt.id  •  (int) ((driv*r->*s*nt_id  ■  (*+driv*r->*v*nt.id))) ; 
n«»_*v*nt_dat*->t in*  ■  (vold*)ulloc(*i*«of  (doable)) ; 

n«v.*v*nt.data->ti»*  ■  (doubl**)Macpy(n**_***nt.dat*->tia*,  tin* ,  driv*r->*iz*of .tin*) ; 

/*  (double* )  eaat  not  is  original  lin.driT . c  cod*  •/ 

11. insert (driv*r->IEQ ,  n*v.*v*nt_d*ta) ; 

return  n**_*v*ut.data->*v«nt_ld; 

} 


/***•••*****■*•••***•*••••••••♦•••••••••*#•*••♦****•*•••**••****•*•••***#•****♦♦/ 

/•  DATE:  03/06/M  */ 

/«  VERSION:  0.0  •/ 

/*  BANE:  Exacnt*  Simulation  function  •/ 

/«  NODULE  IUNBER:  3.3  •/ 

/*  DESCRIPTION:  Allova  th«  u**r  to  «x«cut*  th«  ainulation  */ 

/*  ALGORITHM:  Vhil*  th«r*  az«  event*  aebadultd  ♦/ 

/*  axacuta  tb*  *v*nt  •/ 

/*  load  atata  quaua  •/ 

/*  roturn  * ia.it at*  •/ 

/*  PASSED  VARIABLES:  *dri**r  */ 

/•  RETURIS:  atruct  linkad.liat*  aia.atat*  •/ 

/•  GLOBAL  VARIABLES  USED:  non*  •/ 

/*  GLOBAL  VARIABLES  CBAIGED:  non*  */ 

/•  FILES  READ:  non*  •/ 

/•  FILES  URITTEI :  non*  */ 

/«  HARDWARE  IIPUT:  non*  */ 

/•  HARDWARE  OUTPUT:  non*  */ 

/»  NODULES  CALLED:  ll.aak*  (2.0).  ll.pop  (2.1),  U.inoart  (2.6)  */ 

/•  CALLIIG  NODULES:  aain  (1.0)  •/ 

/«  ORDER  OF:  Thi*  function  ia  of  ordar  0(n)  abara  n  ■  •**anta  in  iEQ  */ 

/•  AUTHOR:  Capt  Rob  Rixza  */ 

/•  HISTORY:  non*  »/ 

/•» . . . . . ****** . •••« . ••*«•*••/ 

struct  link«d_list  **x*cnt*.aia(dr i**r) 
struct  drivar  *dri»*r; 

{ 

itruct  drivar.dat*  *aia_info  *  BULL; 
struct  linkad.liat  *ain_atata  ■  BULL; 


sin.atata  *  ll_a»k*(LIFO) ;  /•  creating  tho  atata  qu«u«  */ 

while  (!(ll_i**apty(driv*r->NEQ))) 

{ 

aLt. info  ■  11. pop  (driv*r->BEQ) , 

driv*r->cui.r_***ut  ■  aia.info;  /*  This  alios*  drivar  to  k**p  track  of  th«  currant  e-irnt  «/ 
(•(aiM_info->fnac))(*iJa.info->fune.*rgu!*ant*>:  /*  *z*cnt*  function  (event)  popped  from  HEQ  -/ 
11. insert (tin. etata,  aia.info);  /•  putting  th*  aia.info  into  th*  atata  queue  •/ 

) 

return  aia.atata; 

) 


/»***«**ee*e**»eee»**ee***e*eee*>ee*« «ee**eee*eee*eee*i 

/e  DATE:  03/OS/M 
/•  VERSION :  0.0 

/♦  BANE:  End  Simulation  function 
/•  NODULE  BUNBER:  3.3 

/*  DESCRIPTION:  Alloaa  tb*  n*«r  to  ond  tho  ainolation 
/«  ALGORITHM:  enpty  tho  IEQ 
/*  PASSED  VARIABLES:  atruct  driver*  driver 
/«  RETURIS:  ll.clear  (dri**r->MEQ) 

/•  GLOBAL  VARIABLES  USED:  non* 

/•  GLOBAL  VARIABLES  CHARGED :  non* 

/»  FILES  READ:  non* 

/♦  FILES  WRITTEN:  non* 


'»/ 

*/ 

•/ 

*/ 

•/ 

•/ 

*/ 

•/ 

•/ 

•/ 

*/ 

•/ 

♦/ 
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/«  f’ARDVIRE  IIPUT:  non*  */ 

/♦  HARDWIRE  OUTPUT :  non*  */ 

t*  «ODWi;s  CALLED :  ll.clssr  <2.3)  */ 

/•  CRLLIIO  MODULES:  clo**_v«*h  (1.3)  */ 

/*  ORDER  OF:  This  function  in  of  order  0(1)  »/ 

/*  RUT10R:  Capt  Rob  Uix*  »/ 

/*  HISTORY:  non*  */ 

struct  driver  *#nd,,sin  (driver) 
struct  drivsr  *dri**r; 

{ 


return  (struct  dri**r*)ll_cla<ir  (dtiw*r*>|EQ)  i 

} 


. . . 

/♦  DATE:  03/06/90  */ 

/*  VERSIOI:  0.0  ♦/ 

/•  BANE:  Print  *t*t*  function  ♦/ 

/•  NODULE  IUNBER:  3.4  ♦/ 

/*  DESCRIPTIOB:  Allows  th*  n*«r  it  ■«•  th*  svent.id  and  it’*  tin*  for  ovary  */ 

/*  event  ♦  / 

/»  ALGORITHM :  Vhil*  output  queu*  is  not  enpty  »/ 

/•  print  «vent_id  and  it’*  tin*  •/ 

/v  PASSED  VARIABLES:  struct  linksd.litt*  stats  »/ 

/•  RETURIS :  non*  »/ 

/♦  GLOBAL  VARIABLES  USED:  non*  ♦  / 

/♦  GLOBAL  VARIABLES  CHARGED:  non*  */ 

/•  FILES  READ:  non*  •/ 

/•  FILES  HR1TTKI :  non*  */ 

/*  HARDWARE  IIPUT :  non*  »/ 

/*  HARDWARE  OUTPUT:  non*  •/ 

/•  NODULES  CALLED:  U.pop  •/ 

/•  CALLIIG  NODULES:  non*  ♦  / 

/•  ORDER  OF:  This  function  is  of  order  0(n)  shot*  n  *  t*v*nts  in  stats  qu*u*  •/ 

/•  AUTHOR;  Capt  Rob  Rizza  •  / 

/♦  HISTORY:  non*  •/ 

/•»*••••••••*•*••'«•**»»**»•*•***•»•••»»•»»••*»»••»*»••»»•»««»••*•***«••***»•••/ 

void  print. stats  (stats) 
struct  linksd.list  vstats; 

( 

struct  driv*r_data  voutput  •  HULL: 


while  ((output  *  (struct  drivor.dsta*)ll.pop(stats))  !»  IULL) 

{ 

int  tia«; 

printf  ("Xd\t" ,  output. ->s**nt. id); 
tin*  *  *(int*)output->tias; 
printf  ("Xd\n",  ti»«); 

) 

) 


/••♦••••••♦»•• . * . . . . . / 

/«  DATE;  07/07/90  ♦/ 

/•  VERSIOI:  0.0  ♦/ 

/•  WANE:  dalot*  ***nt  function  */ 

/*  NODULE  IUNBER:  3.6  ♦/ 

/•  DESCRIPTIOB:  Allows  th*  nsar  to  dolsto  previously  schsdulsd  svonts  using  */ 

/♦  ovont.id  **  Lit*;  dslotion  rofsrsnco  */ 

/•  ALGORITHH:  Whil*  n*zt->it#a  in  IEQ  qusuo  is  not  HULL  •/ 

/•  dsloto  itsn*  with  the  r*f*r«nc*d  ovsnt.id  »/ 

/•  PASSED  VARIABLES :  struct  driver*  driver,  int  event. id  •/ 

/•  RETURIS:  struct  linksd.list*  ♦/ 

/♦  GLOBAL  VARIABLES  USED:  */ 

/»  GLOBAL  VARIABLES  CHAIGED:  non*  •  / 
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/*  FILES  REID:  son*  •/ 

/♦  FILES  VRITTEI:  non*  •/ 

/*  HARDWARE  1 1  PUT :  non*  •/ 

/•  HARDWARE  OUTPUT:  non*  »/ 

/*  NODULES  CALLED:  ll.delete  •/ 

/*  CALLINO  NODULES :  bob*  •/ 

/*  ORDER  OF:  This  f auction  is  s f  order  0(b)  shsrs  n  ■  fevents  la  th«  IEQ  «/ 

/*  AUTIOR:  Cept  Rob  Rina  »/ 

/*  BISTORT:  ROBS  0/ 

/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeaeeeeeeeaeeae..e......*eeee/ 

/»  int  equal. free  (atract  driver. detae  event.deta,  int*  event.id);  ••  generic  eia.driv.c  version  •» 


jtruct  linked. list  edelete.event  (driver,  event.id) 
struct  driver  edriver; 
int  event, id; 

{ 

struct  driver.data  *d«te  ■  BULL; 
struct  linked.list  edeleted.dete  •  HULL; 

deleted. date  ■  11. delete  (driver*>IEQ,  equal.free,  tevent.id); 
data  »  11. pop  (deleted.data) ; 

return  data; 

)  •/ 


int  equal. free  ();  /•  struct  driver.data*  event.data,  into  event. id  version  used  uith  rirsim.c  •  / 

struct  linked.list  edelete.e«ent  (driver,  object. id) 
struct  driver  edriver; 
int  object.id; 

{ 

struct  linked.list  edeleted.data  ■  IULL; 

deleted.data  ■  11. delete  (driver->IEQ,  equal.free,  Aobjeet.id) ; 

return  deleted.data; 

) 


/eeaseeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeseeeeeeeeeeeeeeeeeeeeeeeeeaeeeeeeeeeeey 

/*  DATE:  07/07/90  */ 
/•  VERSIDi :  0.0  e/ 
/•  IANE:  Equal  free  function  */ 
/*  NODULE  IUHBER :  3.6  »/ 
/e  DESCRIPTIOI :  This  is  the  generic  driver’s  function  shich  tells  ll.delete  »/ 
/*  hoe  it  is  to  locate  and  delete  iteas  fron  the  list  •  / 
/•  ALOORITBN:  if  event. id  froa  the  itea  la  the  list  **  event. id  referenced  e/ 
/e  delate  iteas  sith  the  referenced  event. id  •/ 
/•  else  •/ 
/•  continue  looking  to  natch  event. id  e/ 
/e  PASSED  VARIABLES:  struct  driver. data»,  iat  event.id  */ 
/•  RETURIS:  iat  result  */ 
/e  GLOBAL  VARIABLES  USED :  none  e/ 
/v  GLOBAL  VARIABLES  C8AI0ED:  none  •/ 
/*  FILES  READ:  none  »/ 
/ v  PILES  VRITTEI:  none  •/ 
/e  HARDWARE  IIPUT:  none  */ 
/«  HARDWARE  OUTPUT .  none  •/ 
/♦  NODULES  CALLED:  ll.delete  */ 
/*  CALLIIG  NODULES:  none  •/ 


/•  ORDER  OF:  Thia  function  ie  of  order  0(1)  eince  it  siaplj  does  1  comparison*/ 
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/»  AUTHOR ;  Capt  Rob  Rizsa  */ 

/•  HISTORY:  bob*  */ 


/•  int  equal. free  (tvtnt.dtti,  *T*nt_id)  •«  generic  si*_dxie . c  version  *» 
struct  drieer.dets  eerent.dete; 
int  eeeent.ld; 

{ 

int  result  j 

if  (*  vent  _dst  *->*»*. '..id  “»  eevent.id) 
result  -  U.DKL.YIS  I  LL.COHTIIUE; 

•Is* 

result  »  LL.DEL.B0  I  LL.COITIHUE; 
return  result ; 

)  •/ 

int  equsl.fr**  (event.dsta,  object.id)  /•  version  used  Bitb  riisia.c  •/ 

struct  dri**r.dtta  ****nt.data; 
int  eobject.id; 

{ 

int  result: 

struct  event.args  ** vent .argument  “  BULL; 

event.arguaent  •  ***nt_data->func.arguii*nt* ; 

if  (event. arguaent->Qbj*ct2  !*  HULL) 

{ 

if  ( (event. argue*nt->obj*ctl->obj*ct_id  ■■  *obj*ct.id) 1 1 

(*v*nt_*rguaent->obj*et2->obj*ct_id  ■■  *obj«ct.id>) 

result  -  U.DEL.YES; 

else 

result  "  LL.DEL.HO; 

) 

else 

{ 

if  (*vent_argu»i*nt->obj*ctl->obj*et_id  "■  *obj*ct_id) 

result  -  U.DEL.YES; 
else 

result  "  U.DEL.HO; 

) 

return  r«sult ; 

) 
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C.3  The  Carwash  Simulation 

C.3.1  General  Description  The  carwash  simulation  uses  the  functions 
available  in  the  generic  simulation  driver  to  create  a  running  event  driven  simulation 
which  uses  the  following  algorithm. 

The  main  procedure  schedules  only  two  events,  open  the  wash  and  close  t  he 
wash.  Open  the  wash  schedules  the  first  car  arrival.  The  car  arrival  event  checks  to 
see  how  to  handle  each  new  arrival  either  putting  them  in  line  if  the  wash  is  busy  or 
scheduling  them  for  an  immediate  start  wash  if  the  wash  is  empty.  The  car  arrival 
event  also  schedules  the  next  car  arrival  event.  The  start  wash  event  schedules  an 
end  wash  event.  The  end  wash  event  schedules  selected  cars  for  a  rewash.  Re  washes 
are  done  immediately.  End  wash  schedules  a  start  wash  of  the  next  car  in  line  if  a 
rewash  is  not  scheduled.  The  simulation  ends  when  close  wash  is  executed. 

C.3. 2  The  Carwash  Simulation  Code  (hogwash.e) 


. . . . * . . . . . . . *••»/ 

/•  DATE :  03/05/90  •/ 

/•  VERSI01;  0.0  */ 

/♦  TITLE:  Carvaah  Simulation  »/ 

/•  FILliHE :  hogvaah . c  ♦/ 

/♦  COORDIIATQR:  Rob  Rixza  */ 

/*  PROJECT:  EEIG  6S0,  Hintar  90,  Bisbaa  •/ 

/•  OPERATING  SYSTEM:  MS-DOS  •/ 

/•  LAIGUAGE:  Microsoft  Quick-C  »/ 

/•  PILE  PROCESSING:  Conpila  and  link  vith  11. c  and  aim.driv.c  */ 

/•  COITEITS :  1.0  main  -  achadulaa  avasta,  axacutas  simulation  •/ 

/*  1.1  coapars.tima  -  usad  to  aort  avants  ♦/ 

/*  1.2  maka.car.id  -  ganarataa  n  an  car  id  a/ 

/•  1.3  closa.aash  -  aignala  carvaah  ia  cloaad,  anda  ainulation  ♦/ 

/*  1.4  opan.vaah  *  op«na  vaih,  ganarataa  lit  car  arrival  •/ 

/c  l.S  car.arrivss  -  may  vchadula  a  ttart.aaah,  achadulaa  naxt  «/ 

/•  arrival  •/ 

/*  l.S  start .aask  -  achadulaa  an  and.aaah  •/ 

/*  1.7  and.aaak  -  may  sckadula  a  raaaak  or  atart.vaah  */ 

/*  1.0  ratash  -  achadulaa  an  aad.aaah  a/ 

/•  PUICTIOI:  This  fila  implamants  a  carvaah  simulation,  Tha  caraaah  opana,  •/ 

cars  arriva,  tkay  aithar  aatar  tka  aaak  or  gat  in  lina  a/ 

/*  Aftar  baing  aaahad  soma  ara  raaathad.  Simulation  ands  shan  •  / 

/♦  no  mora  unaxacotad  avanta  axiat  or  tha  carvaah  ia  clovvd.  •  / 

. . . . *,*♦♦*.**.,.«,«*♦ . . . . . . 

/•••vaaaaaaaaaaaaaaaaaaaa  CODE  BEGIIS  BERE  aa»aa*a*a*.*aa«a«*.*a*****a*. .*..*/ 


•includs  "11. h" 
tincluda  "aim.driv .h" 
•includa  <atdio.h> 
tincluda  <stdlib.h> 
tincluda  <math.h> 
tinclude  <malloc.h> 
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''♦♦♦••*♦♦♦♦♦•**♦♦♦•♦*♦♦*♦♦♦•*•♦•*••♦♦♦•*•*•*******♦♦*♦•*♦*♦♦♦**♦♦*•**♦♦***«****/ 
/•  uasr  defined  structure  containing  tha  arguments  ectrsash,  etins,  car.il  ♦  / 

/ . . . 

struct  argument. list  { 

struct  driver*  caraaak; 
int*  till; 
int  car. 11; 


>s 


/—•♦**♦*•*****♦*»•***«***»***♦»***♦****♦♦»♦*♦*»•*♦***♦♦» . * . . 

/*  PROTOTYPES  of  «a«r  dsfinsd  functions  »/ 

. . . 


int  coapare.tins  (int*  tiaal,  int*  tinel); 
toil  close.saak  (struct  driver*  caraaak) ; 
toil  open.tash  (struct  argument. list*  argument) ; 
toil*  car.arrlref  (struct  argumont.list*  argument); 
toil  start. task  (struct  arguaent.llst*  argument); 
•oil  and. task  (struct  arguaent.llst*  argument); 
void  reuaeh  (struct  arguaent.liat*  argument); 


/'•»**ee*eeeeeeee*e*e*eeeeeeeeeeeee*eeeeeeeeeee*eeee«eeeeeeeeeeeeeee4*e*eeee*ee/ 
/•  Global  tariablaa :  lino,  and  in.use.flag.  •  / 

/*  »/ 
/•  lino  -  ia  croatod  in  aainO  */ 

/*  -  insorts  into  lino  occur  in  car.arritssO  •/ 

/•  -  pops  occur  in  ond.uaakO  0/ 

/•  in.uss.flag  •  ia  aat  in  atart.aaahO  and  roaaahO  •/ 

/*  -  it  ia  ckockod  in  car.arritasO  •  / 

. . . 

static  struct  linked. list*  lino; 
static  int  in.use.flag  ■  0; 

. . * . * . * . .000..0.000.000.0.0..000..0..0/ 

/♦  DATE:  03/OS/90  ./ 

/«  VERSIOI:  0.0  ./ 

/*  MANE:  nain  •  / 

/♦  NODULE  IUNBER:  J.O  ./ 

/•  DESCRIPTIOI :  Creates  in  instance  of  tke  sinulstion,  schedules  stents,  and  •  / 

/•  sxecutsi  the  sinulstion.  «/ 

/•  ALGORITHM :  create  driter  -  schedule  events  -  execute  events  •/ 

/•  PASSED  VARIABLES;  none  •/ 

/•  RETURIS:  nons  «/ 

/»  GLOBAL  VARIABLES  USED:  line  0/ 

/•  GLOBAL  VARIABLES  CHARGED:  line  ia  created  «/ 

/♦  FILES  READ:  none  0/ 

/•  FILES  VRITTEI:  none,  except  by  redirection  at  run~tiae  */ 

h  HARDWARE  IIPUT:  none  0/ 

/♦  HARDWARE  OUTPUT:  none  e/ 

/•  MODULES  CALLED:  nake.driver  (3.0),  schedule.eteot  (3.1),  4/ 

/*  ll.nake  (3.0),  execute.siji  (3.3)  •  / 

/♦  CALLIR8  MODULES :  none  0/ 

/•  ORDER  OF:  Tkia  function  ia  of  ordor  0(l>  •/ 

/*  AUTHOR:  Capt  Rob  Rixxa  0/ 

/♦  HISTORY:  none  0/ 

/♦♦♦•♦** . . . . . . 

void*  nainO 

{ 


struct  driver*  cartaak; 
struct  arguaant.liat*  arguaont ; 
struct  linked. list*  sia.stata; 

int  tinol  *  0;  /♦  tiael  ia  tk*  start  tine  */ 

int  tia*3  ■  SO;  /•  tina3  ia  tka  closur*  tin*  */ 

if  ((arguasnt«(atruct  argument _liat*)aalloc(siz#of (urruct  argument. list)))~HUl.l.) 
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return  BULL; 


arfrunant~>tin«  ■  Atiael ; 

argument ->caraaeh  ■  (caraash  “  makj.driaar (3,  compare.tiae) > ; 
lin«  «  ll.rake  (FIFO); 

achadule. event  (cuvuh,  Atiael,  open.aaeh,  argument); 
echedale.eTent  (curuk,  lt!a«2,  doM.iuk,  ctnuk)  ; 
sia.atati  “  *zecnt*_aim(car*aah) ; 

'•  print.stats  (eim.etate)  »/ 

> 


/♦♦ 

**•/ 

/♦ 

DATE:  03/05/90 

*/ 

/♦ 

VERSION :  0.0 

*/ 

/• 

BANE:  compar*_tima 

•/ 

/• 

HODULE  BUHBER :  1.1 

•/ 

/• 

DESCRIPTION  Conpare.tiae  is  used  to  toll 

slm.driver  how  to  sort  events 

*/ 

/♦ 

ALGORITHM:  roturn  the  resident  tin*  minus 

the  tiAe  cf  the  itex  to  be 

*/ 

/* 

inserted 

*/ 

/• 

PASSED  VARIABLES'.  eti»cl,  •timm‘2 

*/ 

/• 

RETURBS:  tin  a 2  -  timol 

*/ 

/» 

GLOBAL  VARIABLES  USED:  nona 

•/ 

/• 

GLOBAL  VARIABLES  CBAIGED :  nona 

•/ 

/• 

FILES  READ:  none 

*/ 

/* 

FILES  WniTTER:  nona 

»/ 

/• 

HARDWARE  IIPUT:  nona 

*/ 

/• 

HARDWARE  OUTPUT:  nona 

*/ 

/• 

NODULES  CALLED:  nona 

•/ 

/'• 

CALLIBG  NODULES:  nee.compare.tima  (3.0.1) 

•/ 

/* 

UHLER  OP;  Thia  function  is  of  order  0(1) 

•/ 

/• 

AUTHDii:  Cept  Rob  Rir7.1t 

•/ 

/• 

HISTORY:  nona 

•/ 

. . * . ****** . . . .*..... .<e..e/ 

int  comparo.tiae  (timol  ,  tine2) 
int*  timel; 
int*  time2; 

( 

return  (*tisi«2  -  »ti»al); 

) 


. . . . . 

/«  DATE:  03/05/90  •/ 

/•  VERS I OB ;  0.0  ♦/ 

/♦  BANE;  maka_car.id  */ 

/♦  HODULE  IUJ1BER •  1.2  •/ 

/*  DESCRIPTIOB :  make.car.id  it  ueed  t»  generate  a  car  id  B  */ 

/*  ALGORITBH:  every  tin#  th«  function  i*  called  increment  the  count  •/ 

.  >  PASSED  VARIABLES :  non*  <  / 

/*  REIORBS:  car.id  */ 

/•  GLOBAL  VARIABLES  USED:  non«,  but  car.id  ia  daclarad  static  in  thia  func  */ 

/*  GLOBAL  VARIABLES  CIABGED :  noua  */ 

/•  FILES  READ:  nun*  •/ 

/•  FILES  WRITTEI:  nun*  */ 

/•  HARDWARE  Iim :  nona  •/ 

/*  HARDWARE  OUTPUT :  non*  •/ 

/♦  NODULES  CALLED:  non*  */ 

/•  CALLI/G  NODULES:  open.aaah  (1.4),  and  cai.arrivaa  (1.5)  •  / 

/*  ORDER  OK:  Thia  function  ia  uf  order  0(1)  */ 

/•  AUTHOR:  Capt  Rob  Rizza  •  / 

/»  HISTORY:  none  «/ 

. a.,.*.* . . 

int  maRe.cnr.id  O 

i 
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static  int  car.id  »  0; 
return  ♦♦car.id; 

> 


eaae«ee.e..e.eeae»*a....ao.*.*..**ea*a«aa»aa.aa.aeaaaa/ 

/♦  DiTE:  03/08/90  */ 
/•  VERSIOI :  0.0  •/ 
/•  IAHE:  cloae.sash  •/ 
/•  MODULE  IUMBER:  1.3  •/ 
/•  DESCKIPTI01:  Signals  carsash  is  closad,  snds  the  simulation  */ 
/*  ALGORITHM:  execute  and. sis  {section  */ 
/•  PISSED  V1II1BLES :  •car.saah  •/ 
/•  RETURIS:  sons  •/ 
/*  CLOBAI.  VARIABLES  USED:  sons  •/ 
/*  GLOBAL  VARIABLES  CHARGED:  non*  •/ 
/•  FILES  READ;  nons  */ 
/•  FILES  VRITTEM:  non*  •/ 
/•  HARDWARE  IRPUT :  non*  •/ 
/•  HARDWARE  OUTPUT :  non*  •/ 
/•  MODULES  CALLED:  and.sia  (3.3)  a/ 
/♦  CALLXIG  MODULES:  axecute.sia  (3.2)  •/ 
/•  ORDER  OF:  This  function  ia  of  order  0(1)  ./ 
/•  AUTHOR:  Cept  Rob  Rizxa  •/ 
/•  HISTORY:  none  •/ 
/..•..^.••*aa.a.aaaaaaaeaaaeaaaaaaaaeaa....aaaaaaaaaa*e.aa.a«aaaaaa.aaaaaaaaaaa/ 


void  close.saah  (carvauh) 
struct  driver*  care ash; 

{ 

and.sia.  (enmesh)  ; 

print!  '"SORRY  TEE  C1RWASH  IS  IOV  CLCSED\n\n") ; 

> 


/  .................  eee.eeeeeeeeeeeee*ac.eee***»*e*e.#eeeeeeeeeeeeee.eeaeeeaeeeeee/ 

/•  DATE:  03/05/90  a/ 
/♦  VERSIOI:  0.0  »/ 
/*  IAME :  opan.aaah  a/ 
/a  MODULE  HUMBER:  1.4  •/ 
/*  DESCRIPTION  r  ignale  that  tha  careash  ie  open,  echadulee  let  car  arrival  a/ 
/•  ALGORITHM:  none  a/ 
/♦  PASSED  VARIABLES:  eargusent  a/ 
/•  RETURNS :  none,  but  does  print  a  sassage  to  standard  output  a/ 
/a  GLOBAL  VARIABLES  USED:  none  a/ 
/•  GLOBAL  VARIABLES  CHAIGED:  none  a/ 
/♦  TILES  READ:  none  a/ 
/»  FILES  WR1  TEH:  none  a/ 
/*  HARDWARE  IRPUT:  none  a/ 
/•  HARDWARE  OUTPUT  r.  a/ 
/•  MODULES  CALLED:  .r.id  (1.2),  schedule. eaent  (3.1)  */ 
/a  CALLIIG  MODULES :  ei  ,e_nin(3.2)  a/ 
/  ORDER  OF:  This  function  in  of  order  0(1)  a/ 
/•  AUTHOR-  Capt  Rob  Rizza  */ 
/a  HISTORY:  none  a/ 
. . . . .  . . . . a . . 


void  oi>o-t.eash  (argument) 
struct  gument..liata  argumsr.t ; 
l 

int  first. arrival ; 

print!  ("THE  CARWASH  IS  10V  OPEI .  TIHF.  STAMP  a  Xd'n".  oargua.nt->tise) ; 
aerguiont->t.iae  •  .argum«nt->time  ♦  (randO  X  11)  ♦  i;  /*  creating  next  cer.arrive 
argus.nt->car.id  "  sale. car. id()  ;  /•  creating  next  car ’s  id  • 

schedule. event  (»r(ji:m«iit->carwaah,  argu«ent->t  ise  ,  car. arrives,  argument), 

) 

....  . . . . . a. ae/ 


s  t ime  » / 
/ 
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/•  DATE:  03/05/90  ;/ 
/*  VERSIOI :  0.0  a/ 
/*  IAHE:  car.arrivea  •/ 
/•  MODULE  1 UMBER:  1 .5  •/ 
/*  DESCRIPTION:  Hill  schedule  a  start.sash  event  if  aaih  1  empty,  schedules  */ 
/*  a  car.arrivea  avsnt  a/ 
/*  ALGORITHM:  if  arrival  tiaa  ia  af tar  laat  aaah  azit  ti>a  •/ 
/*  schedule  a  atart.vaaL  a/ 
/•  alaa  a/ 
/•  pat  the  ear  ia  tha  liaa  queue  a/ 
/•  achadula  tha  naxt  <ar  .arrives  aaaat  a/ 
/•  PASSED  VARIABLES:  ‘argument  a/ 
/•  RETUR1S:  none  a/ 
/*  GLOBAL  VARIABLES  USED:  liaa,  in.uaa.flag  •/ 
/•  GLOBAL  VARIABLES  CBAIGED :  aay  iaaart  iato  liaa  a/ 
/*  FILES  READ:  anna  a/ 
/•  FILES  MRITTEI :  none  a/ 
/•  HARDWARE  IIPUT :  none  a/ 
/•  HARDWARE  OUTPUT :  none  a/ 
/•  MODULES  CALLED:  achadula. event  <3.0,  ll.inaart  (2.6),  make.ear.id  (1.2)  */ 
/♦  CALLIIG  MODULES:  execute. aim  (3.2)  ♦/ 
/»  ORDER  OF:  Thia  function  ia  of  order  0(n)  ahara  n  ia  tha  numoer  of  items  */ 
/•  in  )  ina  «/ 
/*  AUTHOR:  Capt  Rob  Rizza  •  / 
/•  HISTORY:  none  a/ 
. . . . . . . . . . . 


void*  car.arrivea  (argument) 
struct  argument.liate  argument; 

{ 

struct  argument  .list  *  nau.  argument , 
int  nav.car.id,  tiaa; 
int*  t iaa.pt r; 

printf  ("CAR  %d",  argument->car_ld) ; 

printf  ("  HAS  ARRIVED  AT  THE  CARWASH.  TIME  STAMP  ■  Xd\n" ,  *argument->time)  ; 

if  (*argunent->tiae  >  in.uaa.flag)  /a  if  aaah  ia  aapty  achadula  immediate  start. wash  •  / 
achadula.avant  (arg\iment->caraaah,  argument ->t  ime ,  atort.eash,  argument); 
alaa  /a  alaa  if  amah  busy  put  car  in  line  •/ 

ll.inaart  (line,  argument) ; 

if  ( (r.aa.arguaant'  (struct  argument. liste)aalloc(Bizaof (struct  argument. list) ) )==RULI.) 
return  BULL ; 

if  ( (tiae_ptr=(inte)m*lloe(sizeof (tiae)))"“IULL)  /*  Dead  to  aalloc  for  int  time  because  •  / 
return  IULL;  /•  dou’t  vent  to  over-urite  same  space  •/ 

/•  in  memory  »/ 

nan.argument ->t ima  «  time.ptr; 

•neo.  arguments  time  "  *arguaent->t ima  *  (rasdO  X  11)  ♦  1;  /♦  nes  car. arrives  time  for  neat  car  •  / 
nea.argument-icareamh  ■  argument ->carvash; 

nes_argument->car_id  ■  make.  car. id();  /»  Baking  nau  car. id  for  next  car  */ 

achedule.ee*  (nes_arguaeiit->carvaeh ,  naa.argumant->tiaa .  car.arrivea,  nau. argument )  ; 

) 

/eeeeeeaaaeaaaaaaaaaaeaeaaaaaeaaaaaaaeeaeaaaaeeeaaaaaaaaaaaaaaaaeaueaaaaaaaeeee/ 


/• 

DATE:  03/05/90 

•/ 

/♦ 

VERSIOI  .  0.0 

•/ 

/• 

IAME :  start  .sash 

•/ 

/♦ 

MODULE  HUMBER:  1.6 

«/ 

/• 

DESCRIPTION  Signals  start  of  aaah.  Schedules 

t  •▼•nt 

•/ 

/♦ 

ALGORITHM:  none 

•/ 

/♦ 

PASSED  VARIABLES:  tuguasti 

•/ 

/♦ 

RETURIS  :  none 

•/ 

/• 

GLOBAL  VARIABLES  USED:  in.uaa.flag 

•/ 

/■ 

GLOBAL  VARIABLES  CBAIGED :  in.uaa.flag 

•/ 
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/•  FILES  READ:  sons  */ 

/*  FILES  VRITTEI :  non*  */ 

/*  HARDWARE  IIPUT :  non*  •/ 

/•  HARDWARE  OUTPUT:  non*  •/ 

/*  MODULES  CALLED:  ach*dul*„***nt  (3.1)  */ 

/*  CALLIIO  MODULE:  OIOCUta.aiB  (3.2)  */ 

/*  ORDER  OF:  This  Sanction  i*  of  order  0(1)  */ 

/«  AUTHOR:  Copt  Rob  Rizzo  •/ 

/•  HISTORY:  nono  •/ 

void  start.vash  (arguasnt) 
struct  argunont.llst*  arguasnt; 

( 

unsignod  int  j  *  0; 

printf  ("CAR  Id",  argua*nt->car_ld)  ; 

printf  ("  HAS  JUST  EITERED  THE  HASH.  TIRE  STAMP-  Xd\n",  *argun.nt->tino) ; 


vhil*  (J**  <  6SOOO)  /*  tia*  to  rood  scroon  loop  •/ 

» 

in_us«_fl*g  -  (*arguaent->tia*  -  *arguaant->tiao  *  5): 

*ch«dul*_*v*nt  (argua*nt~>caroash,  arguasnt ->t  ia* ,  ond.uash,  argument); 

} 


. . . . * . * . * . . . . . 

/•  DATE:  03/05/90  •/ 
/•  VERSIOH :  0.0  ./ 
/♦  SAME:  end.vash  */ 
/•  MODULE  HUMBER:  1.7  »/ 
/*  DESCRIPTION:  Signals  and  of  sash.  Mop  schedule  a  rouash  *v*nt  nr  Bay  »/ 
/»  echodul*  a  start .each  font  for  tho  nrxy  cor  in  lino  */ 
/*  ALGORITHM:  if  a  rondo*  •  noi..  -  3  «/ 
/•  schedule  a  r*vaah  o**nt  */ 
/*  *1 a*  if  th«r*  is  aoaeon*  in  lin*  */ 
/•  sch«dul*  a  atart.sash  *vont  #/ 
/*  PASSED  VARIABLES:  targuaents  »/ 
/♦  RETURNS;  non*  */ 
/•  GLOBAL  VARIABLES  USED:  lin*  */ 
/•  GLOBAL  VARIABLES  CHARGED:  Bay  pop  froa  lino  */ 
/*  FILES  READ:  non*  •/ 
/•  FILES  VRITTEI :  non*  ’/ 
/•  HARDWARE  IIPUT:  non*  >/ 
/*  HARDKAP5  PUTPLT.  POna  */ 
/*  MODULES  CALLED:  sch*dnl«_*v*nt  (3.0,  ll.iseapty  (2.4),  ll.pop  (2  1)  •  / 
/*  CALLIIO  MODULE:  *z*cut*.aia  (3.2)  •/ 
/*  ORDER  CF:  This  function  is  of  oro*r  0(1)  */ 
/*  AUTHOR:  Capt  Rob  Rizza  ./ 
/•  HISTORY:  non*  •/ 
. . . . . 


void  *iid_wasb  (arguaent) 
struct  arguaant.list*  arguatnt ; 

( 

struct  argument .list*  toap. arguaent ; 

unsigned  int  j  *  0; 

printf  ("CAR  Xd",  arguaent ->car_id)  ; 

printf  O'  HASH  IS  FIIISIED.  TIME  STAMP*  Xd\n" ,  »*rgua*nt->t ia«) ; 

•hil*  (}♦♦  <  65000)  />  '-«•  to  road  *r**n  loop  •/ 

I 

if  (randO  X  &  ”  3)  /*  random  aoloction  of  r*va«h*s  •/ 

achedul*. event  (argua»nt->carvath,  arguatnt ->tiae,  r*sa*h,  argument), 

ola*  if  ( !ll_is*«pt/(lin*))  /•  if  you  don’t  g*t  *  reeeeh  got  next  start.vash  •  / 

{  /•  froa  tbs  lin*  if  thoro’s  soaoon*  in  it  */ 

tomp.atgusrnt  *  (ll.pop(liuo)); 
urguiovnt~>c»r_>d  «  t««p_orj<ua*nt ->car_id; 

achedul*. event  (arguaent->cax»»sh ,  arguaent ->t  me,  ntart.vash,  argument). 
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> 

> 


. . . . . 

/*  DATE:  03/05/90  •/ 
/•  VERSIOI :  0.0  •/ 
/•  BANE:  r**aah 

/♦  MODULE  BUHBE A:  1.6  '/ 
/*  DESCRIPTION :  Cars  ar*  la  th*  process  of  being  r**a*h*d  •/ 
/«  ALGORITHM :  bob*  •/ 
/•  PISSED  VARIABLES :  » argument*  */ 
/•  RETURIS :  bob*  *> 
/•  GLOBAL  VARIABLES  USED:  in_ua*_fl*g  */ 
/*  GLOBAL  VARIABLES  CBA1GED:  in_u»*_fl«g  */ 
/•  FILES  READ:  bob*  */ 
/«  FILES  VRITTEB:  ton#  •/ 
/•  BARDVARE  IIPVT:  bob*  */ 
/•  BARDVARE  OUTPUT:  BOB*  */ 
/•  MODULES  CALLED :  »eh*dul*_*T*Bt  (3.1)  •/ 
/*  CALLIIG  MODULES:  *»*eut*_»im  (3.2)  •/ 
/•  ORDER  OF:  Thi»  function  1*  of  ord*z  0(1)  */ 
/•  AUTHOR:  Capt  Rob  Rizza  •/ 
/•  BISTORY :  BOB*  */ 

. . * . . . . . . I 


void  r«unsh  (arguaent) 

str  ict  argtu**nt_li*t*  argument; 

( 

unaignad  int  j  ■  0; 

printf  ("CAR  Id",  argua*nt->car_id) ; 

printf  ("  BAS  E1TERED  FOR  A  REVISE .  TIME  STAMP”  Xd\n",  *arguaent->t ime) ; 
ohil*  < j++  <  65000)  /•  t  1b*  to  road  acr«*n  loop  */ 

in.ua*. flag  *  (*arguB*nt->tii>*  *  ••rgo>»*Rt-->tim*  ♦  5); 

schedule. ***nt  ( argument ->ear*a*h .  argument ->t ia* ,  *nd.»a*k,  argument); 

) 


C  43 


C.3.3  Script  of  Hogwash  Execution 


THE  CARVASB  IS  10V  OPBI .  TIRE  STAMP  -  0 

CAR  1  BAS  ARRIVED  AT  TBE  CARWASH  .  TIRE  STAMP  -  9 

CAR  1  HAS  JUST  EITERED  THE  WASH.  TIRE  STAMP"  » 

CAR  1  WASH  IS  FIIISBED.  TIRE  STAMP-  14 

CAR  2  HAS  ARRIVED  AT  THE  CARWASH .  TIRE  STAMP  -  19 

CAR  2  HAS  JUST  EITERED  THE  HASH.  TIRE  STAMP-  19 

CAR  3  BAS  ARRIVED  AT  THE  CARWASH  .  TIRE  STAMP  -  21 

CAR  2  WASH  IS  FIIISHED.  TIRE  STAMP-  34 

CAR  3  HAS  JUST  EHTEREP  TBE  HASH.  ’'THE  STAMP-  I". 

CAR  4  HAS  ARRIVED  AT  THE  CARWASH .  TIRE  ST  .41  >  2: 

CAR  3  WASH  IS  FIIISHED .  TIRE  STAMP-  29 

CAR  3  HAS  EITERED  FOR  A  REHASH .  TIRE  STAMP-  23 

CAR  3  WASH  IS  FIIISHED.  TIRE  STAMP-  34 

CAR  4  BAS  JUST  EITERED  TIE  WASH.  TIRE  STAMP-  34 

CAR  S  HAS  ARRIVED  AT  THE  CARWASH  .  TIRE  STAMP  •  36 

CAR  6  HAS  ARRIVED  AT  THE  CARWASH .  TIRE  STAMP  ■  36 

..  n  4  WASH  IS  FIIISHED .  TIRE  STAMP-  39 

CAP  o  «,AS  JUST  EITERED  THE  WASH .  TIRE  STAMP-  39 

CAR  7  BAS  ARRIVED  AT  THE  CARWASH  TIRE  STAMP  -  44 

CAR  S  WASH  IS  FIIISHED  '  IRE  STAMP-  44 

CAR  6  HAS  JUST  EITERE./  THE  WASH .  TIRE  STAMP-  44 

CAR  6  WASH  IS  FIIISHED.  TIRE  STAMP-  49 

CAR  7  HAS  JUST  EITERED  THE  WASH.  TIME  STAMP-  49 

CAR  8  HAS  ARRIVED  AT  THE  CARWASH.  TIME  STAMP  >  50 

CAR  7  WASH  IS  FIIISHED.  TIRE  STAMP-  64 

CAR  B  HIS  JUST  EITERED  THE  WASH .  TINE  STAMP-  54 

CAR  9  HAS  ARRIVED  AT  THE  CARWASH  .  TIME  STAMP  •  66 

CAR  8  WASH  IS  FIIISHED .  TIRE  STAMP-  69 

CAR  9  HAS  JUST  EITERED  THE  WASH .  TIME  STAMP-  69 

CAR  9  WASH  IS  FIIISHED.  TIME  STAMP-  64 

CAR  10  HAS  ARRIVED  AT  THE  CARWASH.  TIME  STANP  >  66 

CAR  10  HAS  JUST  EITERED  THE  WASH  .  TIME  STAMP-  66 

CAR  10  WASH  IS  FIIISHED.  TIRE  STAMP-  71 

CAR  1 1  HAS  ARRIVED  AT  THE  CARWASH .  TIKE  STAHP  -  74 

CAR  11  BAS  JUST  EITERED  TBE  WASH.  TIME  STAHP-  74 

CAR  11  HASH  IS  FIIISBED.  TIHE  STAMP-  79 

CAR  11  HAS  EITERED  FOR  A  REVISE .  TIHE  STAMP-  79 

CAR  12  HAS  ARRIVED  AT  TBE  CARWASH.  TIHE  STAHP  -  83 

CAR  11  HASH  IS  FIIISHED.  TINE  STAMP-  64 

CAR  12  HAS  JUST  EITERED  THE  WASH.  TIME  STAMP-  84 

CAR  12  HASH  IS  FIIISHED.  TIME  STAMP-  69 

CAR  13  HAS  ARRIVED  AT  THE  CARWASH .  TIHE  STAHP  •  90 

CAR  13  BAS  JUST  EITERED  TBE  WASH .  TIME  STAMP-  90 

CAR  13  HASH  IS  FIIISHED.  TIHE  STAMP-  95 

CAR  13  HAS  EITERED  FOR  A  REWASH.  TIHE  STAHP-  95 

CAR  14  HAS  ARRIVED  AT  TBE  CARVASH.  TIHE  STAHP  -  96 

CAR  13  HASH  IS  FIIISBED.  TIHE  STAMP-  100 

CAR  14  HAS  JUST  EITERED  TBE  HASH.  TIHE  STAMP-  100 

SORRY  TBE  CARVASH  IS  iOW  CLOSED 
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Appendix  D.  DISPLAY  DRIVER  INTERFACE 
REQUIREMENTS 


This  appendix  is  included  for  completeness  of  this  document.  It  was  taken 
directly  from  the  thesis  by  DeRouchey  (9). 

The  datafile  is  composed  of  records  of  several  types.  Each  record  type  contains 
fields  in  a  specific  format.  The  number  of  fields  in  a  record  is  different  for  each  record 
type.  In  all  cases  the  first  field  contains  an  integer  which  defines  the  record  type. 

Types 

Icon  Assignment  Assigns  an  icon  index  to  a  viewable  object. 


30  G  I 


Example:  30  3  30 


Table  D.l.  Record  Type  30 


Field 

Description 

30 

vecord  Id 

0 

Object  Index  Number 

I 

Icon  Index  Number 

Object  number*  must  begin  with  1  and  be  sequent!?! . 


D-l 


Object  Location  Contains  position  and  orientation  data  for  a  viewable  object. 
The  position  and  velocity  values  have  a  maximum  width  of  eleven  characters.  This 
width  is  inclusive  of  a  minus  sign  and  a  decimal  position.  The  angles  are  measured 
according  to  the  right-hand  rule,  which  is  as  follows:  as  you  look  down  the  positive 
rotation  axis  to  the  origin,  positive  rotation  is  counterclockwise. 


31  0  T  x  y  z  Vx  Vy  Vz  h  p  r  Vh  Vp  Vr 

Example:  31  2  2.5  1000  500  -20  1.2  2.4  -.3  30.0  60.0  -90.0  0.5  5.0  -1.0 
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Table  D.2.  Record  Type  31 


Field 

Description 

31 

Record  Id 

0 

Object,  Index  Number 

T 

Time  (seconds) 

X 

X  •  position  (meters) 

Y 

Y  -  position  (meters) 

Z 

Z  -  position  (meters) 

vx 

velocity  in  x  (meters/sec) 

VY 

velocity  in  y  (meters/sec) 

vz 

velocity  in  z  (meters/sec) 

H 

Heading  (degrees) 

P 

Pitch  (degrees) 

R 

Roll  (degrees) 

VH 

change  in  Heading  (degrees/sec.) 

VP 

change  in  Pitch  (degrees/sec) 

VR 

change  in  Roll  (degrees/sec) 

Icon  Identification  Identifies  an  icon  by  index  and  geometry  description  fil 
name. 


32  I  F 


Example:  32  3  migl 


Icon  number  is  determined  freely  by  the  user. 
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Table  D.3.  Record  Type  32 


Field 

Description 

32 

Record  Id 

I 

Icon  Index  Number 

F 

Icon  Filename 

Object  Termination  Identifies  when  an  object  is  to  be  terminated. 


33  0  T 


Example:  33  3  115.5 


Table  D.4.  Record  Type  33 


Field 

Description 

33 

Record  Id 

0 

Object  Index  Number 

T 

Termination  Time 

Start  Display  Indicates  all  icons  and  the  initial  starting  positions  have  been 
identified  and  sent  to  the  graphics  engine.  The  graphics  engine  can  begin  displaying 
the  simulation. 


50 
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Example:  50 


Table  D.5.  Record  Type  50 


Field 

Description 

50 

Record  Id 

Rtset  Display  Indicates  to  the  graphics  display  system  that  the  simulation  was 
restarted  and  will  begin  execution.  The  graphics  display  system  will  pause  until  a 
START  DISPLAY  is  received. 


52 

Example:  52 


Table  D.6.  Record  Type  52 


Field 

Description 

52 

Record  Id 

End  of  Simulation  Indicates  the  end  of  the  simulation.  This  will  be  the  last 
line  within  the  datafile  that  is  road. 


Example:  86  245.0 


Table  D.7.  Record  Type  86 


Field 

Description 

86 

Record  Id 

T 

Termination  time 

Ordering 

All  icon  identifications  (type  32)  must  occur  before  any  other  type  of  record  in 
(lie  datafile.  Each  viewable  object  must  be  associated  with  an  icon  (type  30)  before 
a  location  record  (type  31)  for  that  object  can  occur  in  the  datafile. 
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Appendix  E.  RIZSIM  Configuration  Guide 


E.  1  Introduction  to  the  rizsitn  Configuration  Guide 

To  run  the  rizsitn  simulation  a  number  of  supporting  files  need  to  be  linked  to- 
gevher.  The  files  needed  to  be  linked  together  are  rizsim.c,  11. c,  sim.driv.c,  sim  J'unc.c, 
a  nd  events. c.  See  Figure  3.6  for  the  file  relationships.  This  configuration  guide  details 
the  compiling  order  of  the  associated  files  to  create  the  executable  rizsitn  simulation 
code.  The  next  section  presents  the  UNIX  makefile  format  used  to  compile  and  link 
the  needed  code.  Other  code  which  also  must  be  present  during  the  compile  and 
link  phase  are  11. It,  sim.driv.h,  simJunc.h,  and  events. h. 

/•'.d  Rizsim  Makefile 

CFLAGS  =  -g 

OBJS  =  sim_driv.o  events. o  sim_func.o  11. o 
LIB  =  -1m 

rizsim:  $(0BJS)  rizsim. o 

cc  -o  rizsim  $(0BJS)  $(LIB)  rizsim. o 

rizsim. o:  rizsim. c 
sim_driv.o:  sim„driv.c 
events.o:  events. c 
sim_func.o:  sim_func.c 
11. o:  11. c 
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Appendix  F.  RIZSIM  USERS  GUIDE 


It  is  not  the  intent  of  this  appendix  to  describe  the  functions,  events,  or  ex¬ 
pected  behavior  of  any  particular  simulation.  It  is  assumed  the  user  already  knows 
how  the  simulation  should  perform  given  a  starting  scenario.  The  intent  of  this 
appendix  is  to  describe  how  the  input  scenario  file  is  created  and  named. 

Currently,  as  the  rizsim.c  code  specifies,  the  scenario  input  file  must  be  named 
“datafile.cM.  If  it  becomes  necessary  to  change  the  name  of  the  input  file  it  can  be 
clone  by  simply  changing  the  read.datafile  function  call  parameter  in  the  rizsim.c 
code  to  correspond  to  the  desired  new  data  file  name. 

Figure  F.l  shows  the  scenario  input  file  format.  All  field  entries  are  manda¬ 
tory  with  the  exception  of  those  fields  which  are  shown  as  “can  be  re¬ 
peated”  fields.  These  fields  are  directly  tied  the  corresponding  fields  directly  pre- 
ceeding  them,  which  gives  the  number  of  times  the  fields  are  to  be  repeated,  if  they 
are  to  be  given  at  all.  For  example,  if  field  27  was  a  5,  then  fields  28,  29,  and  30 
should  be  repeated  five  times  to  accomodate  the  five  sensors.  Conversely,  if  field  27 
was  a  0,  no  entries  for  fields  28,  29,  or  30  would  be  given,  and  the  next  entry  should 
be  field  31. 

Each  field  is  seperated  by  a  single  space.  A  line  of  data  encompasses 
all  data  needed  for  one  object.  A  carraige  return  seperates  lines  of  data, 
thus,  carraige  returns  will  be  after  either  field  43  or  46. 

A  word  of  caution  is  appropriate  at  this  point.  Since  there  is  a  wide  variety  of 
legal  enties  for  each  field  there  has  been  no  attempt  to  determine  if  any  particular 
entry  is  correct.  This  translates  to  mean  that  although  a  created  file  may  be  correct 
format  wise,  it  is  up  to  the  user  to  ensure  that  the  data  entered  is  correct.  Incorrect 
input,  if  not  caught  before  the  simulation  is  displayed  will  undoubtably  result  in 
display  anomalies.  There  is,  however,  some  error  checking  being  done  on  the  input 
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It  is  not  the  intent  of  this  appendix  to  describe  the  functions,  events,  or  ex¬ 
pected  behavior  of  any  particular  simulation.  It  is  assumed  the  user  already  knows 
how  the  simulation  should  perform  given  a  starting  scenario.  The  intent  of  this 
appendix  is  to  describe  how  the  input  scenario  file  is  created  and  named. 

Currently,  as  the  rizsim.c  code  specifies,  the  scenario  input  file  must  be  named 
“datafile. c” .  If  it  becomes  necessary  to  change  the  name  of  the  input  file  it  can  be 
done  by  simply  changing  the  read.datafile  function  call  parameter  in  the  rizsim.c 
code  to  correspond  to  the  desired  new  data  file  name. 

Figure  F.l  shows  the  scenario  input  file  format.  All  field  entries  are  manda¬ 
tory  with  the  exception  of  those  fields  which  are  shown  as  “can  be  re¬ 
peated”  fields.  These  fields  are  directly  tied  the  corresponding  fields  directly  pro¬ 
ceeding  them,  which  gives  the  number  of  times  the  fields  are  to  be  repeated,  il  they 
are  to  be  given  at  all.  For  example,  if  field  27  was  a  5,  then  fields  28,  29.  and  '>0 
should  be  repeated  five  times  to  accomodate  the  five  sensors.  Conversely,  if  field  27 
was  a  0,  no  entries  for  fields  28,  29,  or  30  would  be  given,  and  the  next  entry  should 
be  field  3i . 

Each  field  is  seperated  oy  a  single  space.  A  line  of  data  encompasses 
all  data  needed  for  one  object.  A  carraige  return  seperates  lines  of  data, 
thus,  carraige  returns  will  be  after  either  field  43  or  46. 

A  word  of  caution  is  appropriate  at  this  point.  Since  there  is  a  wide  variety  of 
legal  unties  for  each  field  there  has  been  no  attempt  to  determine  if  any  particular 
entry  is  correct.  This  translates  to  mean  that  although  a  created  file  may  be  correct 
format  wise,  it  is  up  to  the  user  to  ensure  that  the  data  entered  is  correct.  Incom  ct 
input,  if  not  caught  before  the  simulation  is  displayed  will  undoubtahly  result,  in 
display  anomalies.  There  is,  however,  some  error  checking  being  done  on  the  input 
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data  file;  specifically  the  number  of  fields  are  checked  against  those  required  (i.e. 
if  a  mandatory  field  is  omitted  or  if  an  improper  number  of  the  optional  fields  are 
provided,  an  error  message  will  appear  on  the  screen). 

Once  the  input  scenario  file  is  created  and  the  executable  rizsim  code  has  been 
created,  all  that  then  needs  to  be  done  is  to  type  the  executable  file  name.  The 
output  is  sent  to  a  file  called  display.c  in  the  directory  where  the  executable  code  is 
run. 
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field  1 

field  2 

field  3 

field  4 

field  5 

field  6 

field  7 

int 

int 

int 

double 

int 

int 

int 

object  type 

object  id 

1 

curr  time 

fuel  atat 

condition 

■HMM 

field  8 

field  9 

field  10 

field  11 

field  12 

field  13 

field  14 

double 

double 

double 

double 

double 

double 

double 

curr  x  coord 

curr  y  coord 

curr  z  coord 

x  velocity 

y  velocity 

z  velocity 

yaw  rate 

field  15 

field  16 

field  17 

field  18 

I 

field  19 

H 

field  2  i 

double 

double 

int 

int 

int 

int 

int 

roll  rate 

threat  know 

min  turn  rad 

max  speed 

tflHflHBffluHH 

field  22 

field  23 

field  24 

field  2S 

field  2C 

field  27 

field  28 

int 

int 

double 

double 

double 

int 

int 

max  climb 

#  routepts 

x  coord 

y  coord 

*  coord 

#  sensors 

sensor  type 

can  be  rencal  ed 


field  29 

field  30 

field  31 

field  32 

field  33 

field  34 

field  3r> 

int 

int 

int 

int 

int 

int 

int 

sensor  range 

sensor  resolution 

#  armaments 

arm  type 

arm  range 

arm  yeild 

arm  accuracy 

#  sensor  t  imes 


can  be  repeated  #  armament  times 


■  nt 


arm  speed 


int 


arm  count 


field  38 


int 


targets 


field  39 


int 


field  40 


double 


tars  x  coord 


field  41 


double 


field  42 


double 


coord  1  tare  7.  coord 


eated  it  target  times  _ * 


field  43 

field  44 

field  45 

field  46 

int 

int 

int 

int 

#  defensive  »yft|  def  »y<  type 


def  ty«  range  I  def  iyi  effect 


can  be  repealed  #  defensive  eye  times  f 

Figure  F.l.  Input  File  Format 
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